Re: schemas, leveraging their object orientedness??

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
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                      Half-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/
 [mail really from me _always_ has this .sig -- mail without it is forged spam]

Received on Thursday, 23 October 2003 11:38:34 UTC