OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] XHTML 2.0 and the death of XLink and XPointer?

[ 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





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS