[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Alternatives to XML Schemas

  • From: Rick Jelliffe <ricko@a...>
  • To: xml-dev@l...
  • Date: Wed, 07 Mar 2001 03:23:35 +0800

xml schema inheritence
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.


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.