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:] 

Gesendet: Montag, 9. November 2009 14:09
An: 

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: 
 

  
  

    From: 
    "Barack, Ron" 
      <> 
  

    To: 
    "" 
      <> 
  

    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