At 8:53 AM +0100 3/5/02, Eric van der Vlist wrote:
> Title says it all, the extensibility of XML is one of its myths...
> 

Hardly. However, XML is not immune to the old OOP programmer's adage 
that reuse doesn't come for free. You have to design for it and that 
design costs. You won't get the cost back on the first project or the 
second, but you might get it on the third.

> Technically, XML is based on trees which are not the most extensible 
> structures (compared to tables or triples). If you extend a tree you 
> are  likely to break its structure (and existing applications). I 
> would say that trees grow but are not "extended".

Trees most certainly can be extended without breaking existing 
applications provided that the applications are designed to bend and 
not break. I admit that many existing applications are fragile, but 
that's the fault of the application designers, not XML. After all, 
it's the application that breaks, not the XML document.

I've begun to push for applications to be designed around XPath and 
XSLT rather than straight tree navigation because these languages are 
so much better than most navigation based code at handling unexpected 
changes to documents. You still need to design for reuse, and think 
about how your code will react in the face of unpredictable 
modifications, but it's so much easier to do in XPath/XSLT than in 
pure Java/C++/Perl.

In XPath, the single biggest thing most programmers need to learn is 
to treat node-sets as collections that contain 0 to N nodes and not 
as single nodes. In XSLT, you need to make sure programmers don't 
pick xsl:value-of where xsl:apply-templates should be used. Once 
you've done that, your code will handle a lot of common extensions 
and mistakes without falling apart. Of course, you can still change a 
document so radically that the code will break, but this does make 
your application bend a lot further before it reaches its breaking 
point.

> XML is now legacy. Its users community is screaming against any 
> change and its specification body seems paralysed by its structure 
> and the diverging interests of its members...
> 

I would say rather, that we don't want to see the elegance of XML 
marred by needless syntactic extensions to provide features that can 
be cleanly layered on top of the base syntax for those applications 
that need them.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@[...].edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
|             http://www.cafeconleche.org/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>