[
Lists Home |
Date Index |
Thread Index
]
On Tue, 2002-03-05 at 07:46, Eric van der Vlist wrote:
> 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...
I think you're right that XLink is the closest thing we have for graphs
within (and among) documents, but also right that it's not exactly
popular. I suspect that "tree people" stick with XML and very simple
XLink, while "graph people" head to RDF. Those of us in the middle just
kind of wonder.
> > 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.
I agree. I don't believe that's a failing of XML itself so much as its
supporting specifications, however.
> 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.
It'll break a lot of applications, but not all of them. My Regular
Fragmentations work deliberately does such content addition, and
downstream applications may or may not notice. A lot of code written
for SAX will discard the extra element events - avoids breakage, but
doesn't have the desired effect, either.
> 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!
Too many is right. The frameworks are more brittle than the XML
technology which underlies them.
> > 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?
To some extent, yes. How deep do you want the water between islands to
be, though? I'm trying to make those waters shallow and navigable,
rather than assuming they're deep and filled with sharks.
> 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...
I think it was David Megginson who suggested that XML should get smaller
with each iteration. I think there's hope for that eventually, but it
isn't the trend now. Tim Bray's skunkworks proposal
(http://www.textuality.com/xml/xmlSW.html) offers some hope, but I'm not
sure it would so good after a few committees.
> And to consider harmful the few features which are still extensible :) !!!
PIs really seem to bug some people.
> > 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 :) ???
I think you may have already started, and this conversation is just a
small part of it.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com
|
