[
Lists Home |
Date Index |
Thread Index
]
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
|
