[
Lists Home |
Date Index |
Thread Index
]
>> 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 [1]
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.
[1] http://jakarta.apache.org/commons/digester.html
|
