Re: "Re: XML Schema Question"

Hmm...

This is a difficult one, sinceI agree with allmost all of your 
arguments. :-)

What I actually wanted to note is that the solutions we are offering to 
these people are very complicated and validation intensive. If the 
"novice" has control over the format and wants to use XML Schema (and 
this happens in a lot of cases!), he should change his structure or be 
told that this kind of validation is not (reasonably) possible in XML 
Schema... It has to do with the difference with an XML Schema "magician" 
that will try to find need tricks to all kinds of constraints and a guy 
who just has to write a schema to validate some XML used internally in 
his company. For the latter, XML Scheme will only seem more complicated, 
more "out there" and more difficult to understand when not sticking to 
"standard" or "easy" XML Schema uses.

For validators: actually almost every validator I have looked at does 
all validation in one pass, including the one I am writing. This is 
possible because the spec is written with that in mind. (For example: 
Unique Particle Attribution Constraint 
<http://www.w3.org/TR/xmlschema-1/#non-ambig>)

Hope that explains a bit better what I was trying to say :-)

Mik


Jeni Tennison wrote:

>Hi Mik,
>
>  
>
>>There is a very good reason why ordering is preferred to
>>non-ordering and it is the "XML Schema"-way to do things. All of the
>>solutions offered here are overcomplicating implementations and
>>confusing users, pushing them to other validation technologies or
>>wrecking the validation performance.
>>    
>>
>
>What came first, the markup language or the schema?
>
>My philosophy is that the main things that should influence the design
>of a markup language are (in no particular order; their relative
>importance differs for each markup language, and even for different
>parts of a markup language): human readability, size, processing
>efficiency, and extensibility.
>
>If you have a reason why you *have* to use a particular schema
>language (DTD, XML Schema, RELAX NG etc.), perhaps because of tool or
>business constraints such as needing to use XML Spy or only using ISO
>standards, then of course it's reasonable to allow the abilities (or
>lack of abilities) of that schema language to influence the design of
>the markup language.
>
>But in most cases, I'd expect a markup language to outlive a
>particular schema: look at all the markup languages that had DTDs for
>which people now have to write schemas. It seems foolish to
>artificially constrain a markup language because of the weaknesses of
>one particular schema language when you might be using another one,
>without the same problems, in a year's time. (I gather that future
>versions of XML Schema won't have the current constraints on
>occurrence indicators within <xs:all>, for example.)
>
>On the ordering question, I agree that people tend to say "order
>doesn't matter" in their schemas when they shouldn't, but in my
>opinion, it's the job of schema languages to help designers describe
>markup languages, not to limit the designs they can use.
>
>As for the solutions I offered over-complicating validation: it's very
>rare that a single pass of a single schema can check everything you
>need to check about a document; I think it's reasonable to show how
>using several layers of validation can help plug the gaps.
>
>Cheers,
>
>Jeni
>
>---
>Jeni Tennison
>http://www.jenitennison.com/
>
>  
>

Received on Tuesday, 24 August 2004 06:23:14 UTC