Re: extens. and versioning comment

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





-- 
 Chris                            mailto:chris@w3.org

Received on Tuesday, 2 December 2003 13:28:37 UTC