OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: 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.
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,
<?xml version="1.0" encoding="UTF-8"?>

 * <copyright>
 * Service Data Objects
 * Version 3.0
 * Licensed Materials
 * (c) Copyright BEA Systems, Inc., International Business Machines Corporation,
 * Oracle Corporation, Primeton Technologies Ltd., Rogue Wave Software, SAP AG.,
 * Software AG., Sun Microsystems, Sybase Inc., Xcalia, Zend Technologies,
 * 2005-2008. All rights reserved.
 * </copyright>

   These attributes are used to customize the XSD mapping of SDO Types and Properties.

<xsd:attribute name="name" type="xsd:string" />
<xsd:attribute name="propertyType" type="xsd:QName" />
<xsd:attribute name="oppositeProperty" type="xsd:string" />
<xsd:attribute name="sequence" type="xsd:boolean" />
<xsd:attribute name="string" type="xsd:boolean" />
<xsd:attribute name="dataType" type="xsd:QName" />
<xsd:attribute name="aliasName" type="xsd:string" />
<xsd:attribute name="readOnly" type="xsd:boolean" />
<xsd:attribute name="many" type="xsd:boolean" />
<xsd:attribute name="orphanHolder" type="xsd:boolean" />
<xsd:attribute name="key" type="xsd:boolean" />
<xsd:attribute name="embeddedKey" type="xsd:boolean" />
<xsd:attribute name="keyType" type="xsd:QName" />

   Global properties used in open content for 
   the XML binding of SDO Types and Properties.

<xsd:attribute name="xmlElement" type="xsd:boolean"/>

<!-- XMLInfo deprecated in 2.1.0 -->
<xsd:complexType name="XMLInfo">
  <xsd:attribute name="xmlElement" type="xsd:boolean"/>


  <xsd:element name="datagraph" type="sdo:DataGraphType"/>

  <xsd:complexType name="DataGraphType">
      <xsd:element ref="sdo:metamodel" minOccurs="0"/>
      <xsd:element name="changeSummary" type="sdo:ChangeSummaryType" minOccurs="0"/>
      <xsd:element name="orphans" type="xsd:anyType" minOccurs="0" maxOccurs="unbounded" sdox:orphanHolder="true"/>
      <xsd:any minOccurs="0" maxOccurs="1" namespace="##other" processContents="lax"/>
    <xsd:anyAttribute namespace="##other" processContents="lax"/>
  <xsd:element name="metamodel" type="xsd:anyType" abstract="true"/>
  <xsd:element name="xsd" type="sdo:XSDType" substitutionGroup="sdo:metamodel"/>
  <xsd:complexType name="XSDType">
        Expected type is xsd:schema.
      <xsd:any minOccurs="0" maxOccurs="unbounded" namespace="http://www.w3.org/2001/XMLSchema"; processContents="lax"/>

  <xsd:complexType name="ChangeSummaryType">
      <xsd:any minOccurs="0" maxOccurs="unbounded" namespace="##any" processContents="skip"/>
    <xsd:attribute name="create" type="xsd:string"/>
    <xsd:attribute name="delete" type="xsd:string"/>
    <xsd:attribute name="logging" type="xsd:boolean"/>

  <xsd:attribute name="ref" type="xsd:string"/>
  <xsd:attribute name="unset" type="xsd:string"/>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]