On 4/26/09, C. M. Sperberg-McQueen <cmsmcq@b...> wrote:
> On 23 Apr 2009, at 13:26 , Fraser Goffin wrote:
>>
>>
>> Following the debate that an earlier poster referred to, also
>> mentioned the use of a validator, and the meaning was not necessarilly
>> meaning XML schema validation. In many circumstances both XSD itself
>> and validation against XSD is just too brittle.
>
> XSD doesn't require that processors discard things they
> don't understand.  It doesn't require that they keep things
> they don't understand.  (It does specify that if they are in
> the input to validation, they are in the PSVI, but that's not
> quite the same thing.)  It doesn't require that processor fail
> when they see something they don't understand, or when
> presented with an invalid document; it doesn't require that
> they continue processing regardless.  All of those decisions
> are decisions about software and its behavior, and XSD can
> be used in support of any of them.
>
> When we focus on validation as producing a single bit (valid
> or invalid?), any schema language serves primarily to define
> a set of documents (or two:  one set and its complement).
>
> If you want a 1.0 processor for your language to understand
> fully any 1.0 document, but to tolerate 1.1 or 1.2 documents,
> you are essentially wanting to specify two sets of documents:
> the set a 1.0 processor is required to understand, and the
> set it's required to tolerate.  If you specify only one schema
> for 1.0, and focus exclusively on a single bit of the output,
> you are going to find yourself in pain sooner or later.
>
> But is it XSD and validation against XSD that is causing the
> pain? Or is it your failure to say what you mean?
>
> There are a variety of ways to say more clearly what is
> desired, if processors should tolerate material they do
> not understand.  One way is to define two schemas for the
> namespace:  a narrow schema for 1.1 documents and a broader
> schema that 1.1 processors are required to be able to work
> with though they do not understand them completely.  If you
> ensure that there are some documents a 1.0 processor is NOT
> required to tolerate, but required to reject, you allow the
> designers of later versions of the vocabulary to make a
> choice, construct by construct, about whether use of the
> construct should be ignored by a 1.0 recipient which doesn't
> understand it, or rejected.  Another way, as David Orchard
> and others have suggested, is to define the convention that
> an element in the input must be understood if and only if
> it matches an element particle in the content model, NOT
> if it matches a wildcard.  (This essentially defines two
> sets of documents, one in which no wildcards are matched
> and one in which some wildcards are matched.)  A third is
> to require processors to handle not only valid input but to
> soldier on in some prescribed fashion given invalid input.
> I'm sure there are other ways as well.
>
> The hardest thing about versioning for many people to deal with
> is that it requires giving up the notion that we can define
> the world in black and white:  valid documents you are responsible
> for handling in full, and invalid documents you can reject.
> The existence of multiple versions involves accepting the existence
> of multiple, usually overlapping, sets of documents.  That's hard
> for a lot of people to come to terms with; it has less to do
> with the particular schema language they are using than with
> the fact that fuzzy boundaries are harder for our systems
> to deal with than crisp ones.
>
> If anything, I think XSD's explicit support for the notion of
> partial validity makes it more suitable for such situations
> than formalisms in which the output of validation is just a single
> bit.  If you are finding your use of XSD brittle (and I can't
> contradict you if you tell me you are), you might ask whether
> it's XSD, or your way of using it, that contributes the
> brittleness.
>
>
> --
> ****************************************************************
> * C. M. Sperberg-McQueen, Black Mesa Technologies LLC
> * http://www.blackmesatech.com
> * http://cmsmcq.com/mib
> * http://balisage.net
> ****************************************************************
>
>
>
>
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@l...
> subscribe: xml-dev-subscribe@l...
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>

-- 
Sent from my mobile device

---------------
entolution@g...

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php