Re: schemas, leveraging their object orientedness??

cha-ching, thankyou very very very very very much.  I will have to go 
experiment now and see what some of the parsers we use can handle.
yeah,
dean

Henry S. Thompson wrote:

>Dean Hiller <dhiller@avaya.com> writes:
>
>  
>
>>If I have some xml implementating schema A.xsd
>>
>><superclass>
>>    <someElement/>
>></superclass>
>>
>>And then I write B.xsd which extends A.xsd and the xml looks something
>>like this
>><subclass xmnls="......A.xsd">
>>     <someElement/>
>>     <anAddedElement/>
>></subclass>
>>    
>>
>
>Sorry reply to this after so long, hope it will still be useful.
>
>  
>
>>BUT, I must be missing something.  There is now a program A which only
>>knows about A.xsd.  It should be able to receive the xml that adheres
>>to B.xsd and just skip the unknown elements and only deal with the
>>known ones(ie someElement).  The problem is there seems to be nothing
>>to tell the parser that subclass extends superclass unless you know of
>>B.xsd.
>>    
>>
>
>This is indeed a scenario the WG had in mind when designing derivation
>by extension.  I think it works better than you suggest.  It helps to
>distinguish the schema-validation of the documents involved, and the
>processing they receive from the applications involved.  The design
>pattern that works is to validate with the up-to-date schema, but
>process per the original one.  That is, expanding your example:
>
>old.xml:
>
><superclass xmlns="http://www.example.org/cars"
>            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>            xsi:schemaLocation="http://www.example.org/cars
>                                http://www.example.org/cars/schema/v1_0.xsd">
> <someElement/>
></superclass>
>
>new.xml:
>
><subclass xmlns="http://www.example.org/cars"
>            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>            xsi:schemaLocation="http://www.example.org/cars
>                                http://www.example.org/cars/schema/v2_0.xsd">
> <someElement/>
> <anAddedElement/>
></subclass>
>
>v2_0.xsd:
>
><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>           xmlns="http://www.example.org/cars"
>           targetNamespace="http://www.example.org/cars">
> <xs:include schemaLocation="v1_0.xsd"/>
>
> <xs:element name="subclass">
>  <xs:complexType>
>   <xs:complexContent>
>    <xs:extension base="superclassType">
>     . . .
>    </xs:extension>
>   </xs:complexContent>
>  </xs:complexType>
> </xs:element>
>
> . . .
></xs:schema>
>
>I.e. the type definition in v2_0.xsd of 'subclass' is derived by
>extension in the appropriate way from the v1_0.xsd type definition for
>'superclass'.
>
>Now any type-based OO-consistent processing of _either_ old.xml or
>new.xml by an application ignorant of the extended definition will
>work correctly.
>
>By 'type-based' I mean e.g. XPath2.0/XQuery, which will support
>patterns such as "element(*,my:superclassType)" and match them against
>any element whose type is _or is derived from_ my:superclassType.
>
>By 'OO-consistent' I mean using name-based or forward-from-the-beginning
>positional access to the sub-parts of an object.
>
>  
>
>>I thought the idea of extensions was object-orientedness.  The
>>subclass should be able to be read by program A as the superclass.
>>(ie. program A knows about a car, and we created a Ford car, so
>>program A can still see it as a car).  I am afraid that a parser will
>>puke at this since it does not adhere to A.xsd.  There must be
>>something else in the xml I am missing?????
>>    
>>
>
>So the point is that we always schema-validate with the
>version-appropriate schema, but that doesn't preclude processing in a
>early-version-only manner.
>
>ht
>  
>