Menu

A Hyperlink Offering

September 25, 2002

Micah Dubinko

--> achilles (achilles@thinkgreek.com) has joined #xmldiscuss
--> tortoise (tortoise@lewiscarroll.info) has joined #xmldiscuss

tortoise> Good day, Mr. A.

achilles> Same to you, friend.

tortoise> The Web sure makes our frequent conversations easier; it's the most successful communication medium in history.

achilles> Indeed. But is IRC truly part of the Web?

tortoise> Of course. I can imagine a web resource that acts as an IRC gateway, so it naturally follows that IRC is a linked part of the Web.

achilles> How curious that you should mention linking, Mr. T. I was just writing my new web page about Zeno, which includes a link to http://www.shu.edu/projects/reals/numser/answers/zeno.html. I was pleasantly suprised by how easy it is to create links with XHTML 2.0. I simply put an 'href' attribute anywhere I please.

* tortoise scratches head

tortoise> Why, might I ask, don't you use XLink?

achilles> XLink? I didn't see anything in the XHTML 2.0 spec mention XLink. That's not even designed for things like XHTML, is it?

tortoise> Well, according to the spec, which I just happen to have here, "[Definition: An XLink link is an explicit relationship between resources or portions of resources.]"

achilles> That seems rather broad. Ah yes, I seem to remember now, that same document also says: "XLink does not support all HTML linking constructs as they stand". Quite a pity. I wonder how that came to be?

tortoise> What's the point in wondering? XLink is a W3C Recommendation. As a matter of policy, all later specifications ought to be forced to use it.

achilles> Unconditionally?

tortoise> Certainly.

achilles> I learn many new things from you, Mr. T., and this might be another one of them, but how can you say that when SMIL 2.0, XSL 1.0, and even XML Schema have come out with non-XLink links?

tortoise> Oh come now, don't be a heel, Achilles. There wasn't enough time after XLink 1.0 for SMIL and XSL to adopt it. And XML Schema came out before XLink. What's more, XHTML 2.0 is breaking backwards compatibility, so I can't imagine any excuse for them not to use XLink.

achilles> Fair enough. But what you are talking about is a unilateral REQUIREMENT to be placed on all W3C Working Groups.

tortoise> Absolutely. This is the W3C, not a democracy.

achilles> Speaking of requirements, what ever happened to B2?

tortoise> B2?

achilles> Yes, I have a requirements document up on my screen now. It's http://www.w3.org/TR/1999/NOTE-xlink-req-19990224/#syntax. Under B. Mechanical and syntactic requirements, bullet 2, it says: "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."

tortoise> They are to be commended for writing such a clear, direct requirement statement.

achilles> There's more: "For example by supplying appropriate information in an element's definition (in the DTD), such as a default ROLE attribute. This provides for layering of XML link semantics onto large bodies of XML documents without requiring modification of those documents."

achilles> So what happended to B2?

tortoise> Clearly XLink failed to meet that requirement. Nobody's perfect.

achilles> But if XLink had trouble meeting that requirement, what's to say that another Working Group won't have trouble meeting the requirement to use XLink?

tortoise> That's besides the point, my Grecian friend.

achilles> Yes, I suppose. I can always rely on HLink to express my links. That seems to remove the need for having XLink.

tortoise> Oh, dear. That seems rather byzantine. I still maintain that there is no concievable reason, save for some W3C internal schism perhaps, why XHTML shouldn't use XLink.

achilles> It is rather draconian to be limited to one link locator, with a fixed name, per single element, especially in these times of modular language design. One fellow makes a pretty convincing case along these lines at http://lists.w3.org/Archives/Public/www-forms/2002Sep/0210.html.

achilles> In that message, he describes a case where a combined 'host language' ends up with a single <script> element with separate attributes bearing links to content, a security descriptor, and a privacy descriptor.

tortoise> That's just bad markup design.

achilles> ?!

tortoise> That's exactly what extended links are for. The only reason that syntax is unpopular is because a browser vendor from the Northwest U.S. hasn't implemented it.

achilles> Hmmm. Perhaps you are right yet again. Let me sketch out what the element would look like as an extended link: 


    <secureScript  xmlns:xlink="http://www.w3.org/1999/xlink"

                   xlink:type="extended"> 

        <resource xlink:href="/security/pref1.xsp"

                   xlink:type="locator" xlink:label="security"

                   xlink:role="http://example.org/security"> 

        <resource xlink:href="/scripts/pop"

                   xlink:type="locator" xlink:label="script"

                   xlink:role="whatever" /> 

        <resource xlink:type="resource" xlink:label="here"/> 

        <arc xlink:type="arc" xlink:from="here" xlink:to="script"

                xlink:show="embed" xlink:actuate="onLoad" /> 

        <arc xlink:type="arc" xlink:from="here" xlink:to="security"

                xlink:show="embed" xlink:actuate="onLoad" /> 

    </secureScript>
achilles

tortoise> Come now, you exaggerate the complexity. Simply use: 


    <secureScript  xmlns:xlink="http://www.w3.org/1999/xlink"> 

        <resource xlink:href="/security/pref1.xsp"> 

        <resource xlink:href="/scripts/pop"> 

    </secureScript>

achilles> That does seem quite a bit easier to type. How did you do that?

tortoise> Simple. In my DTD, I defaulted all the attributes that are the same from document to document. I could easily do the same in W3C XML Schema, if the desire struck me.

achilles> I see. Your solution has fewer elements. Did you default those too?

tortoise> Pardon? Oh, that. I simply left off the <arc> elements, as well as the one <resource> element with xlink:type="resource". I don't think they matter anyway.

achilles> Hmmm. I'm afraid I have to question your decision to remove those elements, what you've actually just described, in XLink terms, is a two-way link between those two URLs, with the local document having no part in the link! Of if you meant simple links, you just described two unrelated links!

tortoise> Good fellow, you are right. I did intend extended links, and in my haste, I cut too deep. I guess if you defined a special element <local>, all the necessary attributes could be defaulted. So that would leave us with: 

    <secureScript  xmlns:xlink="http://www.w3.org/1999/xlink"> 

        <resource xlink:href="/security/pref1.xsp"> 

        <resource xlink:href="/scripts/pop"> 

        <local/> 

    </secureScript>

achilles> Again, I hesitate to question your greater knowledge and experience with web technology, but there still seems to be a problem.

tortoise> What, pray tell?

achilles> Knowing my forgetful self, I couldn't trust myself to remember to put in that lone <local/> element. And besides, by my reading of the XLink spec, by leaving off all arc-type elements, you've just created a "dogpile" link with N*(N-1) arcs to and from every endpoint.

tortoise> That doesn't bother me.

achilles> It seems a shame to not describe the link accurately, all in the name of author convenience. In fact, it feels enough like cheating to sear my gentle conscience. I still greatly prefer: 


  <script src="/scripts/pop" xsec:prefs="/sec/prefs1.xsp"/>

tortoise> Well, maybe...

achilles> And I have another question. You said you used DTD defaulting. Was that an internal subset or an external DTD?

tortoise> External. My goal was to remove the need for including things in the document to begin with!

achilles> Very good. So what happens if the DTD isn't present, or if a non-validating parser chooses not to look at it?

tortoise> Hmm, that would seem to be a problem. To avoid losing the plot, I guess I would describe my markup language in terms of behaving as if the DTD were always present.

achilles> An interesting design decision. You have just re-engineered the core principle of HLink. To continue down that path, you can also eliminate the singly named locator attribute and its namespace, which removes the obstacle to having multiple locators on a single element. Retroactively, all the way back to XHTML 1.0, I might add.

tortoise> But that's bad markup design! Why would I want to encourage such a thing?

achilles> Bad markup design or not, it's bound to happen eventually. For example, even if XHTML 2.0 could be designed within that constraint, could you guarantee that in all future evolution of the language, as well as in all the possible XHTML+OtherMarkupLanguage permutations, innovation wouldn't be hindered? Just because you don't like a certain way of designing something, should you forbid anyone else from ever doing it?

tortoise> Harrumph. You may have a point, but your proposed solution is no better. HLink has just as limited a domain as XLink does; it just exchanges one set of constraints for another.

achilles> You have a point there. What can we do? Is there no way out?

tortoise> What if the W3C pushed for Working Groups to use a future XLink, just not XLink 1.0?

achilles> Hmmm....

(With apologies to Carroll and Hofstadter)