RE: extens. and versioning comment

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

Received on Tuesday, 2 December 2003 13:50:20 UTC