Re: [sdo] ISSUE 164: Sanity Checks on XSD files

[Bryan Aupperle <aupperle@us.ibm.com>]

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