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

SML - an alternative

  • From: "Stephen T. Mohr" <smohr@v...>
  • To: <xml-dev@i...>
  • Date: Tue, 30 Nov 1999 13:00:49 -0500

index sml core
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

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

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@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@i... the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)


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.
First Name
Last Name
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.