W3C home > Mailing lists > Public > www-tag@w3.org > December 2003

extens. and versioning comment

From: Dean Hiller <dhiller@avaya.com>
Date: Tue, 02 Dec 2003 09:27:02 -0700
Message-ID: <3FCCBD56.7010504@avaya.com>
To: www-tag@w3.org

Hi all,
    I had a comment on the new section on extensibility and versioning. 
 Particularly on these two statements....
1. "Must ignore": The agent ignores any content it does not recognize.
2. "Must understand": The agent treats markup from an unrecognized 
namespace as an error condition.

I am wondering if we can add one here....(this goes back to my use case 
which I currently know 2 projects using xsd's that way)
3. "Must understand items from same namespace but can ignore extensions 
in other namespaces"

There are some instances where you want to validate that at least it 
conforms to the standard namespace, but extra elements from other 
namespaces can still exist as proprietary extensions/features that are 
ignored.  Basically, I want half validated and half ignored.  I have 
attached my versioning use case e-mail below.
thanks for considering this, It is currently very important to two 
different projects that I work on(one open source and one avaya's),

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 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,

Received on Tuesday, 2 December 2003 11:27:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:40 UTC