Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Current status of XLink
 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 ------------------------------------------------------------------------ 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
