xml-dev - Re: SML - a vote against

[Joe Lapp <jlapp@webMethods.com>]

I've decided that I'm also against SML, as it has been unfolding.  Len
Bullard's email (which did not seem to make it into the archive) was the
turning point for me.  We are on the wrong track.  We should not be trying
to re-invent anything.

Instead, what I'd like to see is the codification of subsets and
recommendations for domains of use of these subsets.  For example, in the
domain of XML for business messaging, if not for all of XML-for-data, I'd
like to see a formal recommendation to avoid both entity declarations and
mixed content.  I'd like to make it easy for someone who knows their domain
of use to identify exactly what they need to learn about XML and to learn
just those pieces.  Applications could advertise conformance with various
recommendations to ease both learning to use the application and
integrating with the application.

Perhaps other problem areas could have their own subset recommendations.
What might be an appropriate approach to making this happen?  Is there
interest to do this in other areas where XML is applicable?

At 01:57 PM 11/30/99 +0000, John Aldridge wrote:
>Here's my take on the SML debate...
>
>XML has been designed to be flexible enough to cover a wide range of
>application domains, and to be broadly compatible with some existing
>practice in this arena.  In reaching this design, compromises had to be
>reached between simplicity and this flexibility and compatibility.
>
>We probably all have quibbles about the wisdom of some of the compromises
>reached; but on the whole, I suggest that a good balance has been reached
>between addressing the needs of a broad range of applications, and keeping
>the standard simple enough to be managable.
>
>There will certainly be many applications for which this full flexibility
>is not required; and similarly many applications where compatibility is not
>an issue.  The question is whether, for these applications, the penalties
>of using XML as it stands are large enough to warrant not using it.
>
>The benefit of a single standard is that we will all profit from a rapid
>proliferation and deployment of tools which operate on information
>conforming to this standard.  Every division in the standard dilutes this
>benefit.
>
>The disadvantage is that applications have to carry the implementation
>costs of features which they do not use.
>
>In the end, I think this is a case where be benefits of a single standard
>comfortably outweigh the costs.  Let's stick with the one we've got.
>-- 
>Cheers,
>John
>
>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)
>
--
Joe Lapp                     (Looking for some good people to
Senior Engineer               help create XML technologies that
http://www.webMethods.com     connect businesses to businesses
jlapp@webMethods.com          over the web.)

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)