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

[Elliotte Rusty Harold]

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/    |
+----------------------------------+---------------------------------+