[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Changing Namespaces Between Specification Versions

  • From: Mohan Iyer <mohan@m...>
  • To: "C. M. Sperberg-McQueen" <cmsmcq@b...>, Fraser Goffin <goffinf@g...>, Andrew Welch <andrew.j.welch@g...>, "G. Ken Holman" <gkholman@c...>, xml-dev@l...
  • Date: Sun, 26 Apr 2009 19:27:04 -0700

Re: Changing Namespaces Between Specification Versions
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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.