Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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 --------------- entolution@g... 
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
