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

another real disadvantage I realized is the new Apis for XML Binding. 
 In java, it is typically called JAXB.  They have similar things in C++. 
 This method of extensibility fits great with AXB.  If I have the old 
xsd, I end up with an RegisterDevice object.  If I am using Company B's 
feature, I end up with CompanyBRegisterDevice object instead.  I get 
validation to the point I need validation.  AXB rocks and makes xml so 
much easier to deal with.  In fact, you don't even deal with the XML 
anymore except when using a sniffer.
Dean

Dare Obasanjo wrote:

>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 16:15:53 UTC