OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: xsi:schemaLocation & Parser support?



From: "Prashanth Rao" <prao@vitria.com>

> The last sentence of the above paragraph indicates to me that
> xsi:schemaLocation is an optional feature that parsers can choose to
> implement or not.  This seems to go against the grain of the design
> philosophy of XML:  "The number of optional features in XML is to be kept to
> the absolute minimum, ideally zero."  I know that they are two separate
> specifications, but by relegating xsi:schemaLocation to be an optional
> feature, the specification breeds parser inconsistency, which surely can not
> be a good thing.

Yes, your mistake is tin expecting  XML Schema's design philosophy to be
much related to XML's. If you look in
    http://www.w3.org/TR/NOTE-xml-schema-req
you can find the requirements for XML Schemas.

It is interesting to ask "Have they been met?" and "Would RELAX NG
meet them better?"  (or, indeed, "Does Schematron meet them?")

I haven't found an explicit requirements document or design philosophy
document for RELAX NG.  Schematron has a fairly lengthy (intrusive?)
preamble rationalizing its approach and use
    http://www.ascc.net/xml/resource/schematron/Schematron2000.html

There has been regular criticism of W3C for not opening its archives to
allow its design decisions to be understood.  Of course, with XML Schemas
in particular there was a lengthy community consultation process with
formal answers provided.  And, as people who glimsed the open URI
mail list from last year will appreciate, when an archive gets long pretty
much everything becomes lost anyway.  

That is why mere "openness" of archives is not satisfactory. Indeed, much
valuable information will be missing from any archive because the
phone conversations and private conversations and other shared
understanding and viewpoints will not be made explicit.  Without
explicit design rationales issue by issue, all we are left to judge
a technology by is "oh these guys are experts" or "it looks good
enough" or  "the proof of the pudding will be in the eating", which
is to say "consume, be silent, die" :-(   

I don't want to criticize RELAX NG, because of course
it is a work in progress.  There is definitely some principles in use
(I see in the archives "dare to do less" mentioned, which is like 
Tim Bray's "minimum to declare victory" which cropped up in XML)
and I am no fan of design by slogans (e.g. "simplicity" unaccompanied
"moderation" or "human-centredness" )   I hope they can put out
a clearer statement of their goals and use cases. (Indeed, even
just saying "We are not trying to be a schema language for
large centralized databases; we will not be intellectual overkill for
validating messages." would be nice.)  I am sure it would increase
their credibility even more than a formal model; it would
be interesting to see how much design is taste/philosophy, how much is derived
from practicality of the implementation technologies envisioned, and
how much is derived from use cases.. 

Cheers
Rick Jelliffe