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

This is what wildcards and xsi:schemaLocation are for. I wrote an article about the various extensibility options in W3C XML Schema for XML.com last year. You should read it. 
 
http://www.xml.com/pub/a/2002/07/03/schema_design.html
 
In my opinion, a lot of the features of W3C XML Schema were not designed with practicality or user scenarios in mind. Most of the "object oriented" features of W3C XML Schema fall into this bucket. My advice to anyone designing an XML vocabulary who using W3C XML Schema as a basis for this is to avoid falling into the trap of trying to solve problems in an "object oriented" manner. 

________________________________

From: Dean Hiller [mailto:dhiller@avaya.com]
Sent: Sat 10/18/2003 12:38 PM
To: Dare Obasanjo
Cc: xmlschema-dev@w3.org
Subject: 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

Received on Saturday, 18 October 2003 15:44:28 UTC