RE: versioning use case

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). 
 
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.  

________________________________

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 12:59:28 UTC