xml-dev - SML - an alternative

["Stephen T. Mohr" <smohr@voicenet.com>]

I wonder if the markup community is best served by trying to create yet
another standard.  Clearly, this discussion indicates that XML has problems.
I suspect we'd be better off finding the solution -- we'd have a better tool
without diminishing the momentum behind XML.  In that vein, then, some
thoughts.

People who have built parsers claim the alleged complexity of XML isn't a
problem for them *as XML stands*.  Not having built one of my own, I'll take
their word for it.

As a writer, I'd agree there is a real documentation problem with the
recommendations.  People like me need to explain the Recs to programmers,
but how about better examples in the Recs?  They're kind of thin.  For that
matter, there is an appalling lack of internal consistency in some of the
drafts I've seen.  As a community, we need to find a way to bring newcomers
up to speed without telling them they are incompetent if they don't know the
intricacies of entities, say, on day one.  Coming from the XML-as-data camp,
I seldom have need for them.  The XML-as-publishing people do.  Let's
recognize that different communities exist which require different tool
sets.

As a programmer, I am concerned with the spiraling growth of standards and
apps that build on "core" XML, e.g., XSLT, XPointer, etc.  This is where I
think this list could help.  The same impulses that are driving the SML
discussion should drive us to discuss what the minimal set of standards
should be for a parser.  That is, if you recognize "<?xml version="x.x"?>",
what should you support?  XML 1.0 clearly.  I feel namespaces should be
folded into an update of the XML rec in preference to its orphan status.
The same goes, eventually, for XML Schemas.  But XPath?  XLink?  I think we
could help the community by discussing different levels of processor support
and lobbying W3C for a mechanism for communicating this in documents.  Maybe
a well-known PI or an attribute of the XML declaration.  A processor
encountering a document that requires something beyond the core could
dynamically load a component that supplied that support or reject the
document.  Perhaps there should be a WG on showing how the XML-related
efforts relate, *especially programmatically.*

In summary, then, I think SML is a bad idea being discussed for the right
reasons.  I don't think XML is so badly broken that we need yet another ML
recommendation.  Addressing the problems will require a variety of
approaches.  Let's get at it.




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)