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