[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Alternatives to XML Schemas
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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|