Re: change the question slightly maybe...schemas, leveraging their object orientedness??

Then take this scenario which is very very typical.  Isn't this a big 
problem???
    For example, version 1 of a schema has element "RegisterDevice". 
 Company A had to extend version 1 with it's feature A(inside 
RegisterDevice a field was added), and company B had to extend the same 
schema with feature B(inside RegisterDevice a field was added).  Now 
Company C is a customer using the protocol, and they don't want to use 
either of those proprietary features, but now they can't validate the 
XML to make sure it is conformant to version 1.  This is very very very 
typical.  Why would the standard not require this as part of the parsers 
functionality?

    I personally see this as a big thing.  If XSD was object-oriented, 
it would only care about the superclasses unless Company C had 
companyB's xsd so they could validate the new feature too.  If they 
wanted to be agnostic, they could just make sure it meets the basics of 
version 1 of the schema.  I think XSD would be so much easier to go from 
version to version of all the different protocols out there if XSD was 
more object oriented.  ie A program may use the superclasses and never 
use the data in the subclasses until the next version comes out. 
 Meanwhile, companies can stick their competitive advantage new features 
as subclasses until they can convince the standards board to include it 
in the next version of the standard.
thanks,
dean

Dare Obasanjo wrote:

>It depends. Does the program perform schema validation? If it does then it'll error since the type  xsd2:MyExtendedAddress cannot be located. On the other hand if it doesn;'t then you are fine but then again you don't need a schema to actually get this behavior. 
>
>________________________________
>
>From: xmlschema-dev-request@w3.org on behalf of Dean Hiller
>Sent: Sat 10/18/2003 12:14 PM
>To: Dean Hiller
>Cc: xmlschema-dev@w3.org
>Subject: change the question slightly maybe...schemas, leveraging their object orientedness??
>
>
>
>
>This is a yes or no question.  Just a little long on the xml explaining....
>
>XSD 1....
><complexType name="Address">
>    <sequence><element name="name" type="string"/></sequence>
></complexType>
>
><element name="PurchaseOrder">
>    <complexType><sequence><element name="shipTo"
>type="Address"/></sequence></complexType>
></element>
>
>XSD 2...
><complexType name="MyExtendedAddress">
>   <complexContent>
>      <extension base="XSD1:Address">
>         <sequence>
>             <element name="state" type="string"/>
>          </sequence>
>      </extension>
>   </complexContent>
></complexType>
>
>XML 1
><PurchaseOrder>
>   <shipTo xsi:type="xsd2:MyExtendedAddress">
>        <name>Something</name>
>         <state>CO</state>
>    </shipTo>
></PurchaseOrder>
>
>A program that only has the old XSD1 should only get notified of the
>name, not the state when XML 1 comes in.  Is that correct???  YES or NO
>
>thanks,
>dean
>
>
>
>Dean Hiller wrote:
>
>  
>
>>Anybody? please??
>>thanks,
>>dean
>>
>>Dean Hiller wrote:
>>
>>    
>>
>>>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>
>>>
>>>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.
>>>
>>>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?????
>>>
>>>Also, how would I write the xsd and xml for this?  I wish the
>>>tutorial explained more in this area.  I would say this is by far the
>>>most important part of xsd's.  Extension without breaking previous
>>>programs. Previous programs just ignore additional data.
>>>thanks,
>>>dean
>>>
>>>      
>>>
>>    
>>
>
>
>
>
>  
>