[
Lists Home |
Date Index |
Thread Index
]
On Fri, 2004-03-26 at 17:23, DuCharme, Bob (LNG-CHO) wrote:
> >> So why should relationships be different from objects and attributes,
> >> and require fixed names and fixed semantics?
>
> >Because one may consider that a markup that would have some support for
> >describing graphs might be more useful than one that only supports
> >trees...
>
> I don't think that addresses Mike's point: why does markup that describes
> graphs require *fixed* names and semantics? If I can use an XML 1.0 ID
> attribute, an rdf:ID attribute, an xml:id attribute, or whatever to give a
> particular element identity, I can reference it from another element, and I
> can call that element and the attribute used to identify the link endpoint
> anything I want. The reference is a link, and links between arbitrary nodes
> in the tree can then turn that tree into a graph.
>
> On the topic of a core link markup: once you can establish the identity of
> elements and can then reference those elements using those identity values,
> you've got the core of linking. What other information should a link be able
> to carry? I've got my ideas, Micah has his [1], you've got yours... everyone
> has their own, and that's the problem: once you start adding other pieces of
> information to those two, you've stepped on a slippery slope. Many agree
> that XLink would benefit from being stripped down; let's see them agree on
> what should be taken out and what should be left in.
I think that it's a matter of trade off between features or flexibility
and interoperability.
If you ask around what is a tree and what other information should each
node carry, I'd guess that you would have as many different answers than
when we ask what's a link and what other information should it carry.
But, because most of us on this list have agreed to use the imperfect
definition of a tree given in the XML infoset for our XML application,
we have acquired a certain level of interoperability.
If we agreed on some form of support for simple links in XML, we
wouldn't solve everyone's problems but would gain more interoperability
between applications using that support.
> I wrote recently [2] of how happy I was to see that XML from the U.S. House
> of Representatives models linking around their own classes of resources
> instead of around some external standard that is supposed to support all
> kinds of linking. When you want to view the documents in a browser, the
> links get converted at runtime to a/@href links for your browser. It's a
> very sensible approach, and Mike really summed up very nicely [3] why this
> approach is so sensible, even if he was unaware of the U.S. House documents
> example.
I am not saying that a simple link system would solve all the
problems...
> (On the topics of describing graphs and adding metadata to links, I'm
> tempted to drag RDF into this, but I'll leave that alone for now.)
You mean the "if only RDF could be less intrusive and support mixed
content" permathread?
Eric
> Bob
>
> [1] http://ubinko.info/writing/skunklink/
> [2] http://www.oreillynet.com/pub/wlg/4520
> [3] http://lists.xml.org/archives/xml-dev/200403/msg00476.html
--
If you have a XML document, you have its schema.
http://examplotron.org
Upcoming XML schema languages tutorial:
- Amsterdam -half day- (18/04/2004) http://masl.to/?P220516D7
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
|
