[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Current status of XLink

• To: xml-dev@l...
• Subject: Re: Current status of XLink
• From: "Thomas B. Passin" <tpassin@c...>
• Date: Fri, 26 Mar 2004 12:29:10 -0500
• In-reply-to: <FEF4858E8AB32D4EAC2CF2A7D85386EBE53583@l...>
• References: <FEF4858E8AB32D4EAC2CF2A7D85386EBE53583@l...>
• User-agent: Mozilla Thunderbird 0.5 (Windows/20040207)

DuCharme, Bob (LNG-CHO) wrote:

> 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 there are maybe three fundamental things one wants -

1) A reference to some piece of another document (possible the same one, 
as well).  We get that with <a href=''/>, or a simple xlink:href, as 
long as a URI or an id-marked point exists.

2) Third-party references between documents - this lets you "add" links 
between documents that do not have them embedded.

3) Some way to indicate any semantics of the link.  Remember, though, 
that the semantics the receiver may wish to apply may be different from 
what the sender had in mind.  That kind of flexibility has always been 
the strength of marked-up data and documents.

These simple points leave out some important generic issues.  Here are 
some -

a) Should the linking mechanism point only to xml documents, to html and 
xml documents, or to any kind of data?  Currently, xlink can only point 
to xml documents, although you could maybe stretch the point by 
producing an xpointer scheme that points into non-xml documents.

b) Is there a need for multiple links that belong to the same group 
(e.g., for the same target)?  If so, is there any reason to treat them 
differently from a set of separate links - let the application figure 
out how to present them to the user?

c) Is there a need to have an xml-wide specification of link semantics, 
or should it be left entirely to the xml-based language or the application?

d) Should there be a basic semantic difference between in-document and 
ouf-of-document references?  One might make a case either way on this one.

e) Is there a fundamental need to be able to indicate link semantics 
within the link itself, or is this best left to the application?

f) Is there a fundamental need to indicate the a link is or is not 
expected to "insert" the referenced material into the document?  That 
is, if a link is supposed to insert material into an xml document, it 
would have to be xml content.  If it just references it without 
inclusion, it could be any kind of content.

I think everyone would agree that there is a widespread need for 
in-document references.  Currently this can be satisfied by 
xlink:href='#internal-ref', or by application-defined syntax.  This 
style of usage can certainly be specified to be independent of xlink or 
xpointer.  I would guess that the large majority of xlink:href use is 
for in-document references (svg and topic maps come to mind, even though 
both can use xlink:href for out-of-document references a well).

If there were to be an xml-wide referencing mechanism, then, I suggest 
it should at least provide for the following -

A) Allow in-document references **without** requiring a document to use 
namespaces (other than a default, built-in "xml" namespace).  Right now, 
we cannot even do this much - we have to use the xlink namespace.

II) Provide for graceful extension as consensus is gained.  For example, 
   certain basic link semantics might be agreed on, and the system 
should allow these to be added without changing waht is already there.

3) Provide for out-of document references to other xml documents. 
Possibly this would end up being the same as 1).

D) Provide third-party link capabilities (e.g., link base), although 
this could perhaps come later.

Beyond these basics, everything could be left up to the application.

Cheers,

Tom P

• References:
  • RE: Current status of XLink
    • From: "DuCharme, Bob (LNG-CHO)" <bob.ducharme@l...>

• Prev by Date: RE: Current status of XLink
• Next by Date: DTD questions
• Previous by thread: RE: Current status of XLink
• Next by thread: RE: Current status of XLink
• Index(es):
  • Date
  • Thread