[
Lists Home |
Date Index |
Thread Index
]
Simon St.Laurent wrote:
> This message in particular:
> http://lists.w3.org/Archives/Public/www-tag/2002Jul/0199.html
>
> reads like an acknowledgment that the XLink WG did in fact say more or
> less "the hell with XHTML" (and architectural forms).
>
> History isn't always pretty, and sometimes grudges have real
> foundations.
That post is from me. I feel that Simon's characterization of it is
incorrect and unfair, so why don't I just paste it in and let people
draw their own conclusions. By the way, it ends with a question which I
have yet to hear anybody address, and would like to.
===================================================================
Steven Pemberton wrote:
Steven's been irritated about this for a couple of years now and nothing
I can say is going to change that, but just for the record, here's the
other side of the story - I was only on the XLink WG for a few months
and that ended a while ago so I'm not the best possible source but I
think I have this more or less right.
> It wasn't the XLink charter that lead the HTML WG to believe this,
but the
> XLink requirements document http://www.w3.org/TR/NOTE-xlink-req/, in
> particular requirement B2:
>
> <<<<
> 2: It must be possible to apply XML link semantics to existing
documents by
> modifying the documents' DTDs only, requiring no modification to the
> document instances themselves.
Yes, the XLink WG failed to meet this requirement.
> We also thought that requirement 2.3:
>
> XLink must support HTML 4.0 linking constructs.
>
> meant that XLink would support, well, HTML 4.0 linking constructs. This
> turned out to be a matter of interpretation.
Yes, the XLink WG interpreted this to mean that what they built should
have power and flexibility as rich as that in HTML4.
Where I recall the XLink debate ending up:
- you make any element an xlink by slapping on one or more attributes
from the xlink namespace. E.g. xlink:href, xlink:title
- *all* xlink markup is namespaced
This means that XLink does not provide a way to say that "The 'a'
element is an Xlink and the 'href' attribute is where you put the URI".
The upside is that the design is very clean and never impinges on
anybody else's namespace, and is guaranteed to layer onto any other XML
language with minimal impact on the design of that language.
What *could* have been done was to say that any element that carries an
"xlink:type" attribute is to be considered an XLink, and must have an
"href" attribute for the URI. Or, it could have had something like Norm
suggested, xlink:href-attr-name="href". Both of these would have
allowed treating HTML "a" as an XLink. Neither would have been as
simple and clean as the existing XLink design.
The reason (if I recall correctly) why XLink stayed with the simple
design, and accepted the cost of not grandfathering HTML markup, was
that they couldn't see what the benefit was in the grandfathering.
Every user-agent in the world that processes HTML knows what "a" and
"link" and so on mean, they work well, there's no ambiguity, what's the
benefit in retroactively declaring that they're now also XLinks? I'm
not saying that decision was correct, I'm just outlining the path that
got there.
So, what are some outstanding issues:
- are there things really wrong with xlink such that it should be
deprecated or rebuilt? For example, the decision not to grandfather
existing namespace-free markup?
- there's an obvious overlap between XLink and RDF; how do you decide
when to use which? (Strawman answer: xlink is optimized for the use in
apps that do presentation to humans, RDF for machine precessing).
- if you are going to be building hyperlinks into your XML language, and
xlink provides capabilities do describe what you want, is it OK to go
ahead and invent something else to do the same job? (Strawman answer: no).
> The HTML WG agrees that better linking would be desirable, and seriously
> wanted to use XLink, which is why we spent so much time trying to
achieve a
> version that we could use.
Clearly there's no benefit for HTML to adopt XLinks for untyped
one-directional anchored links, HTML is already very good at that. But
if HTML wanted to add links with multiple ends, or which could be out of
line, or could have some simple behaviors, why invent your own rather
than adopt XLink? The question is serious, not rhetorical. -Tim
|
