sdo message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: AW: [sdo] ISSUE 164: Sanity Checks on XSD files
- From: Bryan Aupperle <aupperle@us.ibm.com>
- To: "sdo@lists.oasis-open.org" <sdo@lists.oasis-open.org>
- Date: Mon, 9 Nov 2009 11:57:37 -0500
You are correct.
Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect
Research Triangle Park, NC
+1 919-254-7508 (T/L 444-7508)
Internet Address: aupperle@us.ibm.com
From:
| "Barack, Ron" <ron.barack@sap.com>
|
To:
| Bryan Aupperle/Raleigh/IBM@IBMUS, "sdo@lists.oasis-open.org"
<sdo@lists.oasis-open.org>
|
Date:
| 11/09/2009 11:23 AM
|
Subject:
| AW: [sdo] ISSUE 164: Sanity Checks
on XSD files |
Hi Bryan,
Datagraph.xsd and SdoModel.xsd
both target the http://docs.oasis-open.org/ns/opencsa/sdo/200812
namespace.
I'm assuming that if we decide
to remove SdoModel.xsd, all we have to do is remove the reference to in
in the sdonamespace.html "RDDL" document. Is that right,
or is there more to be considered?
Best Regards,
Ron
Von: Bryan Aupperle [mailto:aupperle@us.ibm.com]
Gesendet: Montag, 9. November 2009 14:09
An: sdo@lists.oasis-open.org
Betreff: Re: [sdo] ISSUE 164: Sanity Checks on XSD files
As we go through this exercise, we need to consider which of the schema
are normative and thus should be identified by the RDDL documents for the
associated namespaces. I.e. removing schema may result in other document
changes related to defined namespaces.
Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect
Research Triangle Park, NC
+1 919-254-7508 (T/L 444-7508)
Internet Address: aupperle@us.ibm.com
From:
| "Barack, Ron" <ron.barack@sap.com>
|
To:
| "sdo@lists.oasis-open.org"
<sdo@lists.oasis-open.org>
|
Date:
| 11/06/2009 09:18 AM
|
Subject:
| [sdo] ISSUE 164: Sanity Checks
on XSD files |
Hi Everyone,
The last thing to do before release a CD of the core spec is to do sanity
and consistency checks of the included XSDs. There are 3 to consider:
SdoModel.xsd: This schema is problematic.
1) It is not intended to be used by users to validate documents.
I believe the intent was to support implementations "bootstrapping"
their typesystems, possibly also as a machine readable version of portions
of the spec text. But in writing the spec, we should really try to
adhere to "once-and-once-only". If implementations what
to bootstrap from a file like this, they are certainly free to do so, but
I don't see that as a reason to include the file in the spec. If
anything, I can easilly imagine users being confused by the file.
2) There are some technical problems with the contents, in that the "sdoj"
namespace is referenced (Core should not reference Java). My suggestion
would be to simlply remove this file from the CD.
sdoXML.xsd: The main work was to check that the attributes defined
in the sdox namespace are consistent with the spec. I believe they
are. However, I do have some minor revisions:
1) The global attribute "xmlElement" should have type "xsd:boolean"
rather than type sdo:Boolean. This is necessary if we want to get
rid of SdoModel.xsd. Same for the deprecated XMLInfo.xmlElement,
unless we want to consider removing XMLINfo.
2) We can remove references and imports of the sdo namespace.
datagraph.xsd:
1) Why is DataGraphType split into a Base and a Concrete type. I
would recommend combining these.
2) DataGraphType is defined as possibly having metadata in the form
of a contained schema, or in the form of contained EMOF data. The
main problem here, is that this is not extensible (eg, implementations
could support XMI, some proprietary format) Also, we decided early
on to remove references to EMOF from the spec text, it is very odd to see
it for the first time in the XSD. Again, I don't want to disallow
EMOF, I want to make EMOF a possible extension. I think the best
way to do this is for datagraph.xsd to define a substitution group, and
one possible extension (XSD). Implementations can then plug in their
own extensions. The one drawback to substitution groups is that they
are always require prefixes (ie, where in 2.1.1 <datagraph> had elements
that were <xsd>, documents in 3.0 would parse only if the elements
were prefixed <sdo:xsd>). This would be a bigger problem if
we were not changing namespaces anyway. Any implementation that can
parse documents in the commonj.sdo namespace can also parse documents using
the old schema, it is only documents in the new namespace that would have
to be changed. Of course, several examples in the spec text would
have to be changed.
3) We should consider making the schema elementFormDefault="qualified".
I've attached the modified schemas:
I will put this discussion on the agenda for Tuesday's call.
Best Regards,
Ron
[attachment "sdoXML.xsd" deleted by Bryan Aupperle/Raleigh/IBM]
[attachment "datagraph.xsd" deleted by Bryan Aupperle/Raleigh/IBM]
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]