Re: extens. and versioning comment

>>The important point is really ignoring or understanding,
>>which then intersects with rules for various namespaces.

I totally agree and hope this can be covered.  It was not truly covered 
in the XSD spec, and I ran into this situation where I could not 
accomplish validating the standard without validating the proprietary 
extensions.(I was using the latest xercesJ which is XSD spec compliant).
thanks,
dean

David Orchard wrote:

>Dean,
>
>I've thought about this use case a lot and I think it's important and
>common.  Comments inline.
>
>Cheers,
>Dave
>
>  
>
>>-----Original Message-----
>>From: www-tag-request@w3.org
>>[mailto:www-tag-request@w3.org]On Behalf Of
>>Dean Hiller
>>Sent: Tuesday, December 02, 2003 8:27 AM
>>To: www-tag@w3.org
>>Subject: extens. and versioning comment
>>
>>
>>
>>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"
>>    
>>
>
>I think that the TAG and XML schema work covers your example quite well.
>The important point is what to do with unrecognized markup, which may or may
>not be in the same namespace - this is dependent upon the namespace name
>change policy.  There's also the case of where unrecognized markup is in the
>same namespace.  Thus the TAG document does not need to mention namespaces
>in this generalized section, and it does talk more about namespaces later in
>the document.  The important point is really ignoring or understanding,
>which then intersects with rules for various 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),
>>dean
>>
>>
>>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
>>
>>
>>
>>
>>    
>>
>
>  
>