[
Lists Home |
Date Index |
Thread Index
]
At 10:55 12/8/02, Simon St.Laurent wrote:
>Ann Navarro writes:
> > However, sometime in 1999, Xlink stopped describing linking, and
> > started being it. This is a major change, because all of a sudden you
> > are forced to change your documents if you want to use Xlink, even
> > though the current Xlink draft still claims it is a requirement that
> > documents not need to be changed.
>
>That's a very concise description of what the shift from architectural
>forms to namespaces did to XLink. There are some other brittle bits of
>XLink that make it tough to use with XHTML, like the
>one-link-per-element issue, requiring even more rejiggering.
Pretty much... XLink started out trying to grandfather HTML markup. There
were really three options with respect to that requirement:
1) Automatically recognize "href" as the target attribute on a linking element.
This had the drawback that HTML uses "src" as the target attribute on
the img element, and (as others have pointed out) can have multiple
destination attributes on a single element (longdesc and src, for
example). This also has the more general drawback that the attribute name
"href" is now a reserved name in all XML documents.
1a) Automatically recognize "href" as the target attribute only within
documents that are determined to be HTML.
This gets around the drawbacks of 1), and even allows recognition of
different target attributes on different element types, but introduces the
drawback of deciding which documents are HTML documents for all XLink
implementations.
2) Introduce a general attribute renaming scheme à la HyTime.
This was what was in the early drafts of XLink. It had the drawbacks
of being ugly and of being tainted by association with HyTime.
3) Ignore the requirement.
This has the obvious drawback of not meeting the requirement!
The XLink WG (and the XML WG before it) made a good-faith effort at
solution 2). I think it's pretty clear that 1) (and 1a)) were
unworkable. 2) was really killed by politics, as best I can remember;
architectural forms were completely unviable in the W3C environment, and
once namespaces came along, it was pretty much a requirement to use
them. Without attribute remapping, the options were 1) to trample on
users' naming freedom and reserve href across the board (which is still an
incomplete solution for HTML), or 3) to use namespace-reserved
attributes. I continue to think that, given the political restrictions,
the XLink WG made the right decision. 2) would have been stronger, but AFs
just didn't make the political grade.
>My guess at this point is that XLink is wonderful for applications which
>view linking precisely as XLink does, and a pretty complete waste of
>time for applications which have other perspectives. Linking seems to
>produce as many perspectives as schemas, and maybe it's time to stop
>trying to enforce "there can be only one".
I think XLink is a bit more general than that. You do need to have the
same architecture that XLink envisions, it's true: one element for a simple
link, one element per locator plus a wrapper element for extended links,
but I can't think of a general linking solution for which that wouldn't be
true (except some hideously *completely* general solution which would
effectively be a programming language - perhaps links as specified by XSLT
templates that map source into a generic linking language and leave
back-pointers to the original source?).
~Chris
--
Christopher R. Maden, Principal Consultant, crism consulting
DTDs/schemas - conversion - ebooks - publishing - Web - B2B - training
<URL: http://crism.maden.org/consulting/ >
PGP Fingerprint: BBA6 4085 DED0 E176 D6D4 5DFC AC52 F825 AFEC 58DA
PGP signature
|
