Re: Why not XHTML+RDF? was Re: Links are links

Norman Walsh wrote:
>...
> 
> Yes, that's true. But now it doesn't square with my experience with
> actual authors. No one has never asked me to add "exegesis" to phrase
> so that they can connect the phrase to its explanation.

If you are talking specifically about DocBook, then "of course". It 
doesn't have an "exegesis" element, but it does have "fileref", "email", 
"ulink", "linkend" and "otherterm" which are all conceptually links, but 
expressed in terms of an end-user's mental model. (of course DocBook 
predates the current thinking that all of these things should use URI 
references rather than IDREFs...but more modern vocabularies will not)

 >...
> It might also be the case that if I added a 'uri' attribute to every
> element, and told them to put an "xml:linking" attribute on the root
> element of their document with a particular URI value and then to use
> 'uri' on the phrase element, they'd be equally content. I dunno.
> Doesn't actually seem easier to me.

It doesn't seem easier because you've left several differnt kinds of 
links out of the "common linking model" for the Web. And from my point 
of view, why have a "common model" if you're going to use it 
sporadically? You can't do link checking based on it. Your style-sheet 
still needs to know the specific semantics of all of the different 
elements. What benefit did XLink provide? With a single HLink-like 
inclusion, I could turn ALL of those elements into hypertext elements 
and get immediate benefits in hypertext-aware spiders, link checkers and 
    stylesheet engines.

> | Second, when I was talking about simplicity above I was talking about
> | simplicity of the overall specification. XLink is 34 pages when it
> | should be less than 10 if it is going to be baked into every XML tool
> | on the planet (as a truly fundamental linking language should!).
> 
> You think you can describe the syntax and semantics of the out-of-band
> any-linking-semantics-you-want scenario you are suggesting in less
> than 10 pages? I would be very impressed.

We've lost the context of the discussion. I would not mind a 
syntactically rigid XLink if it were essentially baked into XML (and 
thus suitably simple and general). I would just accept its limitations 
as I do the limitations of XML namespaces and attributes because the 
interoperability benefit I would get would be so massive. XML is a 
pretty inconvenient syntax except for those massive interopeability 
benefits. If most or all XML parsers supported a standard linking 
vocabuarly I would use it merely for compatibility and be thankful for 
that compatibility.

Or, on the other hand, I would also be happy with an XLink that totally 
stayed out of my way and could be incorporated into my vocabularies with 
very little cost to my end-users and very little rewriting of my 
vocabularies. It might provide less benefit (by virtue of being less 
widely used) but it would also have a smaller cost to me. And by virtue 
of a lesser cost might end up getting used more.

But today's XLink is intrusive and is only supposed to solve half of my 
problems (by leaving various link types on the table). Plus it is 
complex and confusing enough to dissuade implementors. And it isn't 
supported by any of the W3C specs like XPath, XSLT, XQuery, XML Schema.

I claim that this is why it isn't exactly burning up the charts the way 
xmlns or XPath is.

  Paul Prescod

Received on Friday, 4 October 2002 20:23:39 UTC