Fw: [jdom-interest] Re: Radical Suggestion (was Re: Antwort: RE: [jdom-interest] Namespace help)

[graham glass]

hi elliotte,

what you found was not a "glaring example of electric XML catering
to developer's expectations", it was simply a bug which will be fixed
in the next release of electric XML.

i disagree that the specifications you quote make the diffence between
processing instructions and xml declarations "crystal clear". i spent
quite a long time trying to figure out the intentions of the spec writers
before settling on the current design, and from a quick search on google,
apparently the authors of the oracle xml parser and the microsoft xml
parser made the same mistake (which they have now corrected). i read
through the specs yet again last nite and they still seem pretty vague
on an issue which was (and still is) predictably confusing.

aside from this particular bug, i still have no idea what you're talking
about re: problems with the electric xml API.

frankly, your comments seem bent on taking minor issues and making a huge
deal out of them, which doesn't seem particularly useful or objective.

cheers,
graham

-----Original Message-----
From: jdom-interest-admin at jdom.org
[mailto:jdom-interest-admin at jdom.org]On Behalf Of Elliotte Rusty Harold
Sent: Friday, July 26, 2002 6:49 PM
To: graham glass; jdom-interest at jdom.org
Subject: Re: Fw: [jdom-interest] Re: Radical Suggestion (was Re:
Antwort: RE: [jdom-interest] Namespace help)


At 12:44 PM -0500 7/26/02, graham glass wrote:
>hi there,
>
>what exactly is this "electric XML" fallacy you're talking about?
>

Namespaces are part of it, but hardly the only part. The ElectricXML
API caters to developers' preconceptions about XML rather than what
XML actually is. Very glaring example of this I just noticed a couple
of days ago:

The XMLDecl class implements the ProcessingInstruction interface.

This is completely and totally wrong. Both XML 1.0 and DOM are
absolutely crystal clear that the XML declaration is not a processing
instruction. I admit that many developers think it is a processing
instruction. I've made that mistake myself in the past, but I was
wrong then as you are wrong now.

Every time I look at ElectricXML I find more ways you've attempted to
make XML what developers think it is or what they want it to be
instead of what it actually is. The ElectricXML fallacy is the idea
that you can fix XML in the API.

It is your responsibility as an API developer to faithfully implement
the specs. The programmers who use your API are not XML experts. They
are relying on you to protect them from their ignorance. This a large
part of the purpose of all APIs. For instance, when I use
java.net.Socket I am happy that I can write networking code without
knowing every last detail of the IP packet header format. However, I
suspect that whoever implemented the java.net API (or perhaps the
native APIs it sits on top of) did know every last detail of the IP
packet header format. I would be very upset if I discovered that
because the programmers who wrote java.net didn't like the IP header
format, they used their own instead, especially if they still
described their API as an interface to TCP/IP networks.

XML has some ugly parts, and some things that would be done
differently if we started over from scratch, but you don't have the
right to do this, at least not if you want to use the acronym "XML"
to describe your product. If you really detest what XML is, then feel
free to create your own markup language with its own rules. This may
perhaps look a lot like XML. This is what the MinML and YAML groups
have done, and that's fine. But don't call your product XML when it
isn't.
--

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          XML in a  Nutshell, 2nd Edition (O'Reilly, 2002)          |
|              http://www.cafeconleche.org/books/xian2/              |
|  http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/  |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com