[
Lists Home |
Date Index |
Thread Index
]
Simon St.Laurent wrote:
> On Tue, 2002-03-05 at 02:53, Eric van der Vlist wrote:
>
>>Title says it all, the extensibility of XML is one of its myths...
>>
> I'm not sure it had to be mythical, nor am I convinced that
> extensibility is lost to all of use at this point.
Glad to hear this :) !
>>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".
>>
>
> For some applications, you may be right, and different approaches like
> RDF probably make sense in those cases. Still, I have a very hard time
> imagining writing my data in triples, and a harder time imagining
> triples having anywhere near the transparency that relatively flat tree
> structures have.
Maybe there is just something new to invent there... a markup which
would mark graphs within documents rather than just trees... We are not
that far with XLink, but it's not a core feature and nobody seems to
really care about XLink...
> 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!
> Extensibility scares people - while object-oriented programming, for
> instance, permits all kind of extensibility through class and interface
> structures, it also has best practices which strongly encourage
> encapsulation, hiding all of those details from other parts of the
> program. XML has a tougher challenge here, as it is both extensible and
> extremely open.
>
> I prefer to think of XML as a broad syntax containing all of its
> possible applications rather than as a toolkit for building specific
> vocabularies. This perspective seems to encourage rather different best
> practices than focusing on vocabulary-building. The document contents
> are the foundation of processing, not a particular schema, and the same
> contents need to be visible ("fully composed", as Tim Bray put it
> yesterday) to all comers, without any vocabulary-specific knowledge.
>
> Once we've got that document, we can (and should) go anywhere. Tools
> like schemas, stylesheets, RDDL, and code should let us explore and
> describe possibilities, not choke off anything that doesn't conform to a
> particular vocabulary.
That's fine, but aren't we creating little islands of documents which
are interoperable between themselves, but not between islands?
>>This technical limitation has been strengthen by a community which has
>>become conservative and any evolution seems deamed to fail.
>>
>
> I think the conservatism has always been there. As radical as XML is
> ("Hey folks! Create your own labeled structures for information!"), a
> lot of people have sold it short. Incessant talk about the need for firm
> contracts between parties, a fondness for expert committees, and the
> continuing desire to couple program logic and information as tightly as
> possible are constant themes.
I am also (and maybe more) worried that nobody will ever want to change
the XML 1.0 recommendation and that we'll have ni chance to use what we
have learned since...
> To some extent, it's reasonable. Hurling XML into the world without
> such restraints would likely have created (even more of) a backlash
> against these crazy anarchists. Programmers are pretty conservative
> when it comes to data structures, and I suspect most of them have
> learned firm lessons from the limitations of earlier systems. Tools
> vendors are out to make money selling tools, not extensibility.
>
> I'm can't say I'm very impressed with the "official" line of evolution
> right now. I suspect the W3C is (as it seems to have always been) mired
> in a notion of XML as vocabulary toolkit rather than a syntactical
> continuum, and their output seems to confirm that. Recent discussions
> on www-tag about how tightly to bind processing resources to namespace
> URIs aren't exactly encouraging, either.
And to consider harmful the few features which are still extensible :) !!!
>
> (On the other hand, I'll admit to liking some of the vocabularies
> they're building there.)
>
>
>>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'm not sure that makes XML as a whole legacy. It certainly means that
> those of us who want to do things differently have to get our points
> across in both words and code. I don't see the W3C or the tools vendors
> doing it, and I don't see the people for whom XML is just a small part
> of their job doing it.
>
>
>>It's probably time to look for the next wave!
>>
>
> I suspect the next wave will still be markup of some kind. There may be
> tuples or triples involved somewhere, but I can't see them being on the
> surface. It may be a good time to start making waves, while the vendors
> are all in a corner marveling at Web Services.
>
I hope so, when do we start :) ???
Eric
--
See you in Seattle.
http://knowledgetechnologies.net/
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
http://xsltunit.org http://4xt.org http://examplotron.org
------------------------------------------------------------------------
|
