[
Lists Home |
Date Index |
Thread Index
]
3/5/2002 8:49:45 AM, Nicolas LEHUEN <nicolas.lehuen@ubicco.com> wrote:
>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 ?
Hmmmm ... maybe combining the XML "expose the data, don't encapsulate it"
meme with the OOP "bundle the code with the data" meme? I don't know ...
the "classic" OO ideas aren't scaling to the web as well as markup is,
but I'll bet that the "next wave" is forming out there somewhere in the
nexus between code and 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.
Or cast in concrete, so there's still hope for innovation without
massive disruption. We don't WANT the ink to dry until we have more
experience under our belts, IMHO.
>* 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.
That's an interesting thought ... sortof OO with non-procedural rules
rather than procedural code, bundled with markup data whose format is
exposed rather than encapsulated .... Looks kinda cute and furry to me!
|
