[jdom-interest] API Inertia

[Elliotte Rusty Harold]

At 2:41 AM -0400 5/3/01, Rosen, Alex wrote:
>>  FYI yesterday I realized that I do need to make my own nodes. I'm
>>  thinking about implementing XPointer which adds two new node types:
>>  point and range. These are obviously new classes (Point and Range).
>>  They are also new kinds of nodes in the XPointer data model in
>>  addition to the standard XPath nodes Element, Document, Text,
>>  Comment, etc.
>>
>>  So let's not be so sure that we really don't want client programmers
>>  to create their own Node subclasses/implementations.
>
>That seems weird to me. Why are these "Nodes" (i.e. XML objects)? Can they be
>added to an XML document? What should XMLOutputter do when it sees them?
>

Technically, they're locations, not nodes; and according to XPointer 
locations are a superset of nodes (i.e. all nodes are locations but 
not all locations are nodes). On the other hand you do use the 
point() and range() node tests to identify these locations (and those 
are node tests, not location tests). There are some areas of the XML 
family where things get a little weird. This is one of them. I don't 
know that we should embrace the weirdness, but I don't know that we 
should pretend it doesn't exist either.

As to what an XMLOuputter should do when it sees them? I'm not sure. 
It would certainly be easier to handle if the nodes themselves were 
responsible for their own serialization. For points I suspect, no 
output is necessary. Points are zero dimensional. For ranges, I'd 
expect the content of the range to be output, from the beginning of 
the range to the end of the range.

Here's another example of a case where you might want to provide your 
own node subclasses: according to the XML InfoSet each character is 
its own information item. You might plausibly want to make characters 
nodes, though most of the time you probably wouldn't need this.

The problem is that there's more than one plausible data model for an 
XML document. Should JDOM pick one and stick to it? or should JDOM
operate purely at the level of syntax? or should JDOM try to be 
adaptable to multiple data models? These are deep questions and they 
haven't really been addressed. JDOM is sorely lacking a requirements 
document that can be used to answer questions about what is and isn't 
in scope and what methods should and should not be provided.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+