W3C home > Mailing lists > Public > xmlschema-dev@w3.org > August 2004

Re: XML Schema Question

From: Jeni Tennison <jeni@jenitennison.com>
Date: Mon, 23 Aug 2004 17:46:57 +0100
Message-ID: <1829529198.20040823174657@jenitennison.com>
To: Mik Lernout <mik@futurestreet.org>
CC: xmlschema-dev@w3.org

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.



Jeni Tennison
Received on Monday, 23 August 2004 16:47:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:15:23 UTC