[
Lists Home |
Date Index |
Thread Index
]
On Mon, 2002-01-14 at 08:38, Manos Batsis wrote:
> I think the summary of what's wrong about XML (and SGML) is that it is
> conceptually incompatible with the rest of mainstream technologies.
> XML's hierarchical model (not to mention abstract XML models that go
> beyond the hierarchical boundaries) does not fit to relational DBs and
> procedural programming (thus far). So, either we cripple XML in our apps
> to be able to handle it easily, or mess a mess out of our XML handling
> code/storage (which, BTW today, goes through so much useless
> transformations and runtime modifications so that it wont break Mr. X's
> code).
I like this summary of "what's wrong about XML" very much. Markup
(which I'll use here as a more general term than XML) does NOT fit the
relational models or procedural approaches which are common throughout
computing, and its fit with objects is tenuous at best.
Trying to make markup work in what I'll call a "legacy" environment is
much more difficult than many people seem to think it should be, and the
difficulty factor increases substantially the more markup's capabilities
for freeform hierarchy are taken seriously.
The problem seems clear. However -
> What XML needs is (as I have heard a number of times on this
> list) a high level dynamic API.
>
> High level, to stop worrying about elements and attributes and focus on
> the actual abstract meaning of the contents.
> Dynamic, to provide an efficient memory representation and run time
> handling of the XML data, meaning their abstract representation, not the
> one that just mirrors nodes.
>
> The problem is that to (possibly) achieve such high level handling, we
> have to hit metaprogramming techniques (meaning, the API should be aware
> of the abstractions via an *abstraction* schema language)... Which of
> course may make things worse (while another schema language may be the
> last thing we need right now).
This sounds like completely the wrong solution to me - "another schema
language" which attempts to coerce markup into playing nicer with
existing programming notions seems likely to merely compund the ugliness
of the current schema language which attempts the same thing (aka W3C
XML Schema).
I see only two ways around the mismatch between markup and the wide
variety of other programming universes:
1) Use markup sparingly, in as constrained a manner as possible. Coerce
marked-up documents into looking like the data you're used to seeing -
tables or objects. There are real processing, efficiency, programming,
and learning costs to this coercion, so sparingly is likely a wise
idea. (I see things like W3C XML Schema, SOAP, XML-RPC, data binding,
and other related projects in this space.)
2) Take markup seriously, and accept that information may not always
come in precisely the same structure. Write code which supports
flexibility rather than demanding conformity. Throw away notions of
strict conformance to semantical notions - rely only on syntactical
conformance. (I see things like XSLT and RELAX NG as providing
foundations for work in this area, though I don't think anyone's really
explored the territory well.)
There is definitely a mismatch between how markup describes information
and the ways in which other branches of computing expect information.
If you insist on living by old expectations, you're bound to be
disappointed, though at least you're more likely to hold a steady job at
a profitable company.
If you want to move beyond those conventional ways of computing and take
a stab at working with 'wild' markup, people may think you crazy, but I
suspect the work will be more interesting if not necessarily lucrative.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com
|
