RE: extens. and versioning comment

Dean,

You are confusing validating with understanding.  validation is separate,
though potentially related to understanding.  It is quite possible for an
application to have the schema for content that it does not understand, and
not have a schema for content it does understand.

The current finding is at [1].  An older version of the finding [2] had
considerable mention of xml schema specific constructs.  The plan is to
republish the xml schema specific constructs in a separate document, but
this won't happen for a few weeks.  If you find the separation of schema
useful or not useful, that would be valuable feedback.

Cheers,
dave

[1] http://www.w3.org/2001/tag/doc/versioning
[2] http://www.w3.org/2001/tag/doc/versioning-20031003

> -----Original Message-----
> From: www-tag-request@w3.org
> [mailto:www-tag-request@w3.org]On Behalf Of
> Dean Hiller
> Sent: Tuesday, December 02, 2003 11:48 AM
> To: Chris Lilley
> Cc: www-tag@w3.org
> Subject: Re: extens. and versioning comment
>
>
>
> 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.
> thanks,
> dean
>
> 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 15:13:19 UTC