Re: An XLink telco issues roundup arguing for XLink remapping

Lloyd Rutledge wrote:

> The most important misconception may be that XLink discussion is
> between "elementists" and "attributists".  Perhaps the groups are
> better described as "elementists" and "choicists", or better:
> "element-alwaysists" and "remapping-if-and-when-best-ists".  I sense
> that the key division is in whether or not the XLink elements can be
> hidden from authors through a simplifying remapping while providing
> browsers and bots with the required access to the XLink-defining
> element structure.  I am convinced, as are others, that a remapping
> meeting these requirements can be created and should be pursued.

Fair enough.  I retain my strong feeling that for multi-way links, an 
element-based rather than attribute-based design is more natural, safer, 
and perfectly easy to grok for humans doing a "View Source".  I also 
think that having the linkage markup explicit in the instance probably 
hits an 80-20 point, and that furthermore link existence is arguably 
part of the content not presentation.  And I'm less convinced than Lloyd 
that language designers are going to want to invent their own linking 
syntax and do remapping.

I think that if the HTML WG were to move to a linkage architecture that 
absolutely did not support element-based links (as HLink does not) and 
were to move absolutely all linkage out of the instance into a 
stylesheet, this would cause profound architectural discomfort and not 
just in the TAG, and the path to recommendation would be fraught with 
difficulty.

If someone wants to take the initiative to build an alternative 
mechanism with a bias towards out-of-line storage and attribute-based 
markup, why not give it a try?  The only caveat I can think of is that 
any such design had better be pretty sensitive to i18n issues or it has 
a real architectural problem.

The recent telecon changed my mind on one significant issue - it seems 
apparent on further consideration that the "show" attribute of XLink is 
pretty presentational and it's probably an excellent idea to move it 
out-of-line.  I'm less convinced about "actuate" - as Tantek pointed 
out, if you want to do a "full copy" of a web page, you probably want to 
take the equivalent of "src=" links but not the "href=" style.

> All of the HTML, SMIL, etc. documents
> currently on the Web, and in any event most of those coming up in the
> next year to two, have no XLink elements in them.  An element-only
> XLink will keep the links in these documents hidden.

I don't believe this argument for a second.  All the 'a' and 'img' 
elements in HTML and SMIL are now first-class citizens and are 
recognized by every piece of software that claims to do anything with 
HTML or SMIL.  How would the introduction of XLink change that?

=====================================================

Conclusion: if I were da boss, and had infinite amounts of design time 
to invest, here's what I'd do.

1. Redraft XLink, making the following changes and calling it "XLink 
Basic" or XLink-- or some such:

a) allow the xlink:type attribute to be inferred as proposed earlier. 
If you see an xlink:href and your parent attribute has 
xlink:type='extended', then infer xlink:type='locator'; otherwise infer 
xlink:type='simple'.  Poof - half the Xlink markup vanishes.

b) lose xlink:actuate and instead, as Micah and others have suggested, 
just use xlink:src='foo' or xlink:href='foo' with the classic 
well-proven HTML semantics.

c) lose xlink:show entirely and use the CLink machinery

d) make it clear that all the arc stuff is entirely optional for those 
who don't want to use it.

2. If the HTML WG wants to invent a special-purpose schema language for 
general linkage syntax remapping, they should do so and bring it forward 
for community feedback.  I think we can all agree that HLink was an 
interesting first step.

3. Write support for XLink-- and HLink++ into XHTML 2.

4. See what happens. -Tim

Received on Sunday, 26 January 2003 18:25:16 UTC