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

Re: [SML] Numeric character references

  • From: "Michael Champion" <mike.champion@s...>
  • To: <xml-dev@i...>
  • Date: Sun, 28 Nov 1999 11:35:58 -0500

numeric character references and trademark

----- Original Message -----
From: <rev-bob@g...>
To: <xml-dev@i...>
Sent: Sunday, November 28, 1999 10:24 AM
Subject: re: [SML] Numeric character references

> > Accomodating the coder's convenience in the language
> > itself is the first step on the road to another SGML.  A higher level
> > or API can easily handle the conversion, so put it there, not in the
> And here I thought the whole purpose of SML was to make things simpler for
> *user*, not to make things easier on lazy programmers.  Silly me.

It's interesting how many different senses of "simple" keep coming up in
these threads.  I guess I think of  SML  as "minimal" rather than "simple to
use".  So you're right -- SML is not likely to make coding markup "simpler"
for the user who knows the XML spec well.

Minimalism *does* have long-term advantages to the end user because the
tools they use will tend to be less buggy, delivered on time, etc.  More to
the point, the higher-level abstractions and APIs built on top of SML will
be easier to use because they don't have to hide as much underlying
complexity as XML APIs do.

I've also noticed that the term "lazy" keeps coming up to describe
developers who aren't thrilled about implementing the entire XML spec.  I
think of it rather differently ... as some Clint Eastwood character says, "a
man's gotta know his own limitations" (spoken over the corpse of some Bad
Guy, as I recall). Software developers have to rigorously manage complexity
to produce anything that has a prayer of working right anytime soon.
Nobody's mentioned in this thread that David Brownell has found that almost
none of the XML parsers out there are fully conformant to the spec, and
that's not because the developers are lazy or stupid.  A programmer who
understands his/her own limitations and desires to focus on implementing
*well* the subset of XML that delivers the most power is not lazy, IMHO.

> Passing something as simple as hex <=> dec conversion over to a
> different component doesn't remove the complexity - it just shuffles it

Again, you're probably right about this simple example, but I still think
"SML"'s support for numeric character references should be kept minimal as a
matter of principle.  As always, if you don't like the principle, SML
probably has little benefit for you anytime soon.  Don's not trying to
convert everyone to the cause, just to establish legitimacy for those who --
for various reasons -- wish to focus on a minimal subset of SML.

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.