Lists Home |
Date Index |
- To: firstname.lastname@example.org
- Subject: RE: [xml-dev] RELAX NG Marketing (was RE: [xml-dev] Do Names Matter?)
- From: "Bullard, Claude L (Len)" <email@example.com>
- Date: Tue, 26 Mar 2002 08:58:16 -0600
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
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
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.
From: James Clark [mailto:firstname.lastname@example.org]
My two cents is:
- RELAX NG has achieved depressingly little success so far in terms of
- 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