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

Re: extens. and versioning comment

From: Dean Hiller <dhiller@avaya.com>
Date: Tue, 02 Dec 2003 12:47:52 -0700
Message-ID: <3FCCEC68.5050907@avaya.com>
To: Chris Lilley <chris@w3.org>
Cc: www-tag@w3.org

I feel that it maybe precluded by the architecture document only in this 
statement which seems black or white...
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.

This was the same thing in the xsd spec almost.  It was all or nothing. 
 There was no in-between which is what I am requesting.

Chris Lilley wrote:

>On Tuesday, December 2, 2003, 5:27:02 PM, Dean wrote:
>DH> I am wondering if we can add one here....(this goes back to my use case
>DH> which I currently know 2 projects using xsd's that way)
>DH> 3. "Must understand items from same namespace but can ignore extensions
>DH> in other namespaces"
>I had proposed that one as well, but it was found in yesterdays telcon
>to be too complex.
>DH> There are some instances where you want to validate that at least it
>DH> conforms to the standard namespace, but extra elements from other 
>DH> namespaces can still exist as proprietary extensions/features that are
>DH> ignored.
>Yes. This might be a better example for the finding, which has the
>space to go into more detail.
>DH>  Basically, I want half validated and half ignored.  I have
>DH> attached my versioning use case e-mail below.
>DH> thanks for considering this, It is currently very important to two
>DH> different projects that I work on(one open source and one avaya's),
>DH> dean
>Do you feel that this case is precluded by the Arch Doc? I don't
>believe it is.
>DH> I was told by someone recently that you were recently talking
>DH> about versioning, and I started looking at your posts(haven't
>DH> caught up yet).  Someone suggested I send you my use case. 
>DH> Hopefully this is not a repeat use-case that you may already have.
>DH> This discussion is on the xmlschema-dev list.  The topic is
>DH> "schema xsi:type validation question".
>DH> Basically, I was looking for an extension mechanism similar
>DH> to OO.  Take the following XML for example...
>DH> <ns1:element xsi:type="ava:ExtendedElement">
>DH>    <ns1:data/>
>DH>    <ava:moredata/>
>DH> </ns1:element>
>DH> ns1 is the namespace of the standard.  ava is the namespace
>DH> of some companyX's extension to that standard(proprietary feature
>DH> not in the standard yet). 
>DH> If I want to be compliant with the standard, I make sure I
>DH> don't use any proprietary features from any of the companies.  I
>DH> don't want to validate companyX's extension(the ava:moredata
>DH> element), just that there is enough data that meets the minimum
>DH> requirements to be compliant with the standard(the ns1:data
>DH> element).  After all, there are many other companies that have
>DH> extended the "element" and added their own proprietary stuff too. 
>DH> On top of that, my customer that uses my client is in a high
>DH> security area and the parser cannot download new schemas of the
>DH> web.
>DH> This is sometimes how standard api's work.  Say I have a
>DH> class Phone(like in JAIN), and I have a special feature on the
>DH> Phone that other companies don't have.  I subclass phone with
>DH> AvayaPhone which has extra proprietary functions not in the
>DH> standard yet(yet, because obviously we want them in the standard).
>DH> A customer who wants to be able to connect to any server will just
>DH> use Phone and never use the AvayaPhone.  
>DH> JAXB also helps greatly in the area, because the above XML
>DH> could be unmarshalled into a "Element" if the companyX schema was
>DH> not present ignoring all the extra data.  If the customer had
>DH> companyX schema, the XML would be unmarshalled into an
>DH> ExtendedElement.  Very slick and clean.  At least I think so.  You
>DH> guys have probably been thinking about this much longer.
>DH>  thanks for considering this,
>DH>  dean
Received on Tuesday, 2 December 2003 14:47:55 UTC

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