RE: XML doesn't deserve its "X".
>> Extending trees isn't difficult so long as you haven't tightly bound >> yourself to a particular vision of how the tree must absolutely >> postively precisely be structured. If you're willing to accept that >> adding a new branch to a tree or reorganizing a branch doesn't >> automatically make it a diabolical mutant, there's a lot more >> flexibility. > >That's not that easy and there is nothing in the specs which helps to >create the discipline required in the applications to make it smooth. > >Let's take a simple example... I have a text only element: > ><ns1:foo>This is a simple example.</ns1:foo> > >If I extend this example to include a semantic element to identify >"simple" as an adjective: > ><ns1:foo>This is a <ns2:adj>simple</ns2:adj> example.</ns1:foo> > >I am changing a text leaf node into a mixed content including 2 text >nodes separated by a child element and this will likely break 90+% of >the existing applications. > >The situation is probably better if you want to add an element in an >elements only content model, but even in this case, if you take real >life applications, how many of them will you break? 30%, 50%, >75% ? Way >too many in any case! That's because extensibility is not something that can be achieved by looking at the data only. I'm sorry to ressurect my old rant "meaning is not in data alone, it's both in data AND code", but alas, it's still true here. Due to the way we write programs to process XML data, we weave a set of implicit patterns or schemas within our code, which resembles closely to the explicit schema of the XML data (that is, if there is such a schema). BTW, by schema I mean of course any kind of structural constraint on the document, not specifically schemas written in XML Schema. As soon as the explicit schema is changed, there is a mismatch with the implicit schema woven in the code, and the result is the code is broken. The only way I see out of this problem is not to think about how we could make XML more extensible, because it cannot be more extensible by itself. We should rather look for design patterns to make our XML processing code support schema evolution*. Like Simon noticed, we haven't truly achieved extensibility in XML, but we have done quite well with OOP through the inheritance and implementation mechanisms. Maybe the solution is simply to leverage those mechanisms when writing code that processes XML data ? Problem is, I have the intuition that an OOP design pattern that allows extensible processing of XML data this will require to use PSVI. And this is a part of XML specs where the ink hasn't dried yet, to say the least. Concerning your example with ns1:foo, an example of programming for extensibility could be to have a Foo interface with a String getText() method. If you want to extend your ns1:foo element with the possibility of mixing foo2:adj element with text, you could have a FooWithAdj interface, inheriting from Foo, with a method <whatever> getTextAndAdjs(). In the implementation, getText() would simply strip out the adj tags, while the getTextAndAdjs() would return the full monty. This way, any old piece of software that would rely on the Foo interface would still work, while new code could benefit from the FooWithAdjs interface and features. Note that a simple transformation could be used in this case, retrofitting the new schema into the old one with a stylesheet because handling it to the old code, but the OOP approach may be useful for complicated transformation and/or when you have to mix old and new code within the same program. I don't know if this pattern is part of the solution, but at least it's not part of the problem :). Now, there may be other ways out. Maybe it's time to build a new programming paradigm that goes further than OOP, which precisely handles this extensibility problem. Go ahead, but I'm not smart enough, so I'll stick to OOP for now :). Regards, Nicolas * I've been quite fascinated by the Apache Jakarta Commons Digester  approach, which takes rules that can build objects, launch methods, etc. I think this kind of rule-driven XML data processing is quite interesting to investigate. Maybe using rules is a way to handle extensibility more easily.  http://jakarta.apache.org/commons/digester.html
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format