Cart
[Home] [By Thread] [By Date] [Recent Entries]
Just some thoughts: Many knotty problems of markup applications are centered in designing and promoting an application language. There are two qualities which impress me about a given schema: a) Composability - how natural is it to build with the language in its application domain. Is it easy to learn? Can one do a lot of useful work just knowing some basic productions and then learn more as needs arise? This is where HTML and most gencoding approaches thrive. b) Transformability - how many languages can be derived from an instance of one. We think of a schema in terms of defining an application language (sg, SVG), yet really, it is just a data domain for many, particularly, databases. Given some domain, how many application languages can use it as a data source? This is where HTML and most gencoding approaches fall apart. Didier is making this point by differentiating the rendering schema systems from the data schema systems. Next, how easy is it to write the transforms that allow these sources to be used easily? I ask this because we should better understand what people can and will do with schemas before we declare any schema design language down and out in the market. There aren't too many people conversant with the skill today. 1. XML for all the noise is still a young technology. Many markets are just now getting down to the early work of adopting it for the simpler tasks. 2. Schemas, for all the noise, are still far and few between. Because of the emphasis on well-formedness, some number of those just adopting XML are working in the mode where an XML instance is handled and validated in code. 3. There is still an opportunity for a better net/browser framework, properly layered and easier to build with to emerge. That it must be supported by Microsoft is undeniable at this time. 4. DSDL has a chance to make an impact. A well layered design that supports features such as the schematron approach to co-occurrence constraints is needed. Don't take forever getting this done. All of this has to be balanced against a world where some programmers are talented enough to do it all, while others script against a framework. Support for this latter group is vital to success on the web. Even where we have talented well-trained computer scientists, production issues still dominate management thoughts about Internet systems and services. Tell us why RELAX NG is a more productive approach. Technical elegance impresses, but even with the perception of juggernaut, productivity tools still make a difference. As to the perception of the W3C as owning all XML specs and standards, many share some of the blame for that if there is blame to be shared. The savaging of ISO and SGML in the last decade came at a price. Now is when we pay it and maybe take home a life lesson for the price. len -----Original Message----- From: James Clark [mailto:jjc@j...] My two cents is: - RELAX NG has achieved depressingly little success so far in terms of market adoption. - However, it would be premature to throw in the towel. The RELAX NG spec was finalized less than 4 months ago. XML is going to be around for a long time to come and there will be a continuing need for an XML schema language. XSD is not suddenly going to become radically simpler. Even if RELAX NG is only adopted by a small percentage of the XML market, the XML market is big enough that this is still worthwhile. - RELAX NG needs more evangelizing. I think for both Murata-san and myself it would be fair to say that our strengths are in the technical department more than the marketing department. - The key difficulty facing RELAX NG is that the W3C is perceived as owning the XML core standards space; it is very hard for any specification to compete with a W3C Recommendation in this space, especially when that Recommendation has been adopted by the big players including Microsoft. It will be hard for RELAX NG to compete no matter how brilliantly it is evangelized.
|
