Alternatives to XML Schemas

[Rick Jelliffe <ricko@allette.com.au>]

Just to note where we (putting users hat on)

 - DTDs remain, providing defaulting and fixing attribute values even for
non-validating processors (reliable in standalone documents) and giving a
schema
even though just as documentation

 - DTDs remain in validating processors, providing simple datatyping
suitable for symbolic and text processing, and simple content modeling, but
with a little clunkiness in the area of namespace

 - Architectural forms remain, layerable on top of fixed attribute
definitions and with specifications of type available through SAX processor
XAF.

  - Datatyping on top of DTDs remains, e.g., the conventions in
http://www.w3.org/TR/dt4dtd to allow datatyping using DTDs.

 - second-generation an DTDs remain: SOX, XDR, DCD, DSD

 - third-generation DTDs are available: XML Schemas, TREX, RELAX, with
   a common set of datatypes

 - rule/path based languages such as Schematron (and the Schematron-like
languages such as Libby's Schemarama "SQUISH" demo) and Finkelstein's
XLinkit are available

 - alternative languages such as Hook (experimental for very small
languages)
   and some other unreleased onces also exist.

 - diagramming models combined with transformations into XML languages,
   such as UML.

I cannot imagine that we won't have some kind of XML Schemas subset before
too long (indeed, I mentioned this before.) Murata-san and James Clark
clearly have some desire that their Schema languages provide good models for
such a thing.

So what would be really useful would be (apart from more experimentation)
for groups such as XML-DEV and SML-DEV to work up some requirements or
use-cases targetting whereever XML Schemas may be considered weak.  I am
sure that such a list would be greeted by some marketeers as merely creating
confusion (apparantly this is a great crime rather than the natural
consequence of premature standardization) but, as I mentioned last week,
from my time in the WG I do think that XML Schemas fills a good high-end
need--but if someone says it does not fill all needs or some important
use-cases (e.g. related to light-wieghtedness, power, extensbility,
non-disruption of other standards, interoperability issues for claiming to
be XML but being XML++, etc.) then I couldn't argue with them.

(And certainly I don't want to hose down any consideration of the
desirability of the XML++ PSVI infoset by promising everyone will feel
better in the morning when/if we have a subset.)

Reading Alexander's pattern book "A Pattern Language" yesterday (on the
plane with a guy who had worked with Alexander to build a school in Japan),
he mentions that it seems that shops of the same type are better off being
far from each other so that they have their own unique catchments but that
shops of different types are better off being together because they benefit
from people attracted to other shops.  The same might be true of schema
languages: datatypes and Schematron can happily work with other languages
because it is neutral, but I expect that a viable, simple 3rd-generation DTD
would have to either be a subset of XML Schemas and/or be clearly targeted
to have a different catchment (user-base or problem-base.)

Cheers
Rick Jelliffe

P.S. Tangentially, Hosoi-sensei, the plane man, said that Alexander worked
by conducting extensive interviews with over 60 stakeholders, then creating
a customized version of the pattern language (with either over 85 patterns
or over 200 patterns, I cannot remember); this pattern language, in a sense,
became the requirements specification for the school: "we abandoned
rationality" was how it was put...meaning that conventional wisdom was not
followed and that optimizations that went against patterns (such as having a
running track rather than a big pond) were not followed.  He said the school
is a success; very nice fellow.

The interesting thing that struck me was that patterns are not used as
recipes for solving some medium-sized problem, but as timeless ways of
building independent of a particular problem, that, when selected correctly
and appropriately, will combine to create successful places with soul. This
seems different to the uses in OO patterns.

Furthermore, reading Alexanders book it seems to me that he considers
patterns to be reflections of human nature; this is particularly interesting
to me because the same priniciple can be sought in markup languages (as
pieces of Human Computer Interaction): that there are human ways of
understanding that some markup idioms (e.g. inheritence) are better for than
others.  It would be great if there were some empirical tests of what these
feature might be.