Re: versioning use case

thanks for your reponse.  my comments are inline....

Dare Obasanjo wrote:

>Authors of W3C XML Schema documents already have mechanisms to deal with this as do implementers of W3C XML Schema processors. Schema authors can prevent type substitutability with the block & blockDefault attributes. Similarly schema validators can be requested to ignore schema location hints in which case the fragment below would fail to validate (as long as the ns1:element type had a processContents of strict on its wildcard as opposed to lax or skip). 
>
This is exactly what I mean though.  A company has extended the schema 
using "extension", yet I don't want their additional features.  I just 
want to validate the base schema is ok.  I can't.  It is all or nothing. 
 I have to validate base schema plus the companies additional 
elements(their extension), or I can't validate it at all.  If I can't 
validate at all, I don't know if the data that comes in is enough to 
meet the base schema requirements and my app might break.(in fact, I run 
into cvc-elt.4.2 because the companies type can't be found.)

>I suspect the problems you are having have less to do with W3C XML Schema and more to do with whatever API you are using to process validated documents.  
>
While this is true, and a #any element could have been used inside the 
Element.  I could then validate the Element without validating what is 
in any.  The only thing is I think it is much cleaner to do extension. 
 It is like OO.  I guess I am suggesting a much cleaner mechanism.  I 
think this would help with JAXB, and I belive .NET has something 
similar, where instead of ending up with an Element class containing a 
PrivateData class containing the extended data, .NET would end up with 
an ExtendedElement class if it existed or an Element class if the 
ExtendedElement class did not exist(ie. other extended data is ignored). 
 This method fits great with new technologies that the #any does not. 
 It makes alot of architectures much cleaner.

>
>________________________________
>
>From: www-tag-request@w3.org on behalf of Dean Hiller
>Sent: Sat 11/22/2003 8:58 AM
>To: www-tag@w3.org
>Subject: versioning use case
>
>
>I was told by someone recently that you were recently talking about versioning, and I started looking at your posts(haven't caught up yet).  Someone suggested I send you my use case.  Hopefully this is not a repeat use-case that you may already have.  This discussion is on the xmlschema-dev list.  The topic is "schema xsi:type validation question".
>
>Basically, I was looking for an extension mechanism similar to OO.  Take the following XML for example...
>
><ns1:element xsi:type="ava:ExtendedElement">
>   <ns1:data/>
>   <ava:moredata/>
></ns1:element>
>
>ns1 is the namespace of the standard.  ava is the namespace of some companyX's extension to that standard(proprietary feature not in the standard yet). 
>
>If I want to be compliant with the standard, I make sure I don't use any proprietary features from any of the companies.  I don't want to validate companyX's extension(the ava:moredata element), just that there is enough data that meets the minimum requirements to be compliant with the standard(the ns1:data element).  After all, there are many other companies that have extended the "element" and added their own proprietary stuff too.  On top of that, my customer that uses my client is in a high security area and the parser cannot download new schemas of the web.
>
>This is sometimes how standard api's work.  Say I have a class Phone(like in JAIN), and I have a special feature on the Phone that other companies don't have.  I subclass phone with AvayaPhone which has extra proprietary functions not in the standard yet(yet, because obviously we want them in the standard).  A customer who wants to be able to connect to any server will just use Phone and never use the AvayaPhone.  
>
>JAXB also helps greatly in the area, because the above XML could be unmarshalled into a "Element" if the companyX schema was not present ignoring all the extra data.  If the customer had companyX schema, the XML would be unmarshalled into an ExtendedElement.  Very slick and clean.  At least I think so.  You guys have probably been thinking about this much longer.
>
> thanks for considering this,
>
> dean
>
>
>-------- Original Message -------- 
>Subject: 	schema xsi:type validation question	
>Resent-Date: 	Fri, 21 Nov 2003 11:02:17 -0500 (EST)	
>Resent-From: 	xmlschema-dev@w3.org	
>Date: 	Fri, 21 Nov 2003 08:59:57 -0700	
>From: 	Dean Hiller <dhiller@avaya.com> <mailto:dhiller@avaya.com> 	
>To: 	xmlschema-dev@w3.org	
>
>
>Hi all,
>    having a huge discussion over on the xerces-J list right now.  I got 
>the impression from somone on this list that if I had this XML
>
><ns1:element xsi:type="ava:ExtendedElement">
>   <ns1:data/>
>   <ava:moredata/>
></ns1:element>
>
>I could validate against the ns1 namespace and ignore the ava namespace. 
> I am being told on the xerces list this is not true according to the 
>specification, which I think I may agree that the specification states 
>this is not true.(though I don't agree with having that in the spec)
>
>First, let me give a small background on the entire problem.  I am 
>writing a client that I want to communicate a standard 
>protocol(namespace="ns1" above).  I don't want to use any extensions 
>from any companies(namespace="ava" above).  My client is typically 
>behind a firewall and can't get the extra schemas.  It only gets what I 
>ship with it.  I only ship the standard as I communicate with all 
>servers that implement the standard.  Problem is some companies extend 
>their schema as above and they all extend differently for the extra 
>features they offer.  This naturally makes me want to process and 
>validate Element without validating ExtendedElement.
>
>Now to the spec, the spec has item 4.3(spec section pasted below) which 
>states the local type definition must be validly derived from the type 
>definition.  Unfortunately, since xerces is not given the extended 
>schema(or the other 100 companies extension on the standard), it cannot 
>verify 4.4 so cannot declare the element to be locally valid.  I 
>personally think, this is big mistake to do this, because there are 
>situations you just want to validate the superclass without validating 
>the subclass, like my above scenario.
>
>----------------------------------------XSD BEGIN 
>SPEC------------------------------------
>4 If there is an attribute information item among the element 
>information item's [attributes] whose [namespace name] is identical to 
>http://www.w3.org/2001/XMLSchema-instance and whose [local name] is 
>type, then all of the following must be true:
>4.1 The ·normalized value· of that attribute information item must be 
>·valid· with respect to the built-in QName simple type, as defined by 
>String Valid (§3.14.4);
>4.2 The ·local name· and ·namespace name· (as defined in QName 
>Interpretation (§3.15.3)), of the ·actual value· of that attribute 
>information item must resolve to a type definition, as defined in QName 
>resolution (Instance) (§3.15.4) -- [Definition:]  call this type 
>definition the local type definition;
>4.3 The ·local type definition· must be validly derived from the {type 
>definition} given the union of the {disallowed substitutions} and the 
>{type definition}'s {prohibited substitutions}, as defined in Type 
>Derivation OK (Complex) (§3.4.6) (if it is a complex type definition), 
>or given {disallowed substitutions} as defined in Type Derivation OK 
>(Simple) (§3.14.6) (if it is a simple type definition).
>--------------------------------------XSD END 
>SPEC------------------------------------
>
>thanks for any help or suggestions here,
>dean
>
>
>  
>

Received on Saturday, 22 November 2003 13:12:42 UTC