Push Button Paradise

User-Centered URL Design

Great article on a usability aspect often overlooked. -m

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

tortoise>Good day, Mr. A.

achilles>Why, same to you friend.

tortoise>The Web sure makes our frequent conversations easier. In fact, the web is 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>My, 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 than when SMIL 2.0, XSL 1.0, and even XML Schema have since 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 your 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 ever 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>Boy, I have a typing cramp now! I had to leave off arcroles and labels even.

tortoise>Come now, you exaggerate the complexity. Simply just 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 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 read 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>Vey 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 it's 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>Harumph. 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 XLink, just not XLink 1.0?

achilles>Hmmm.....

(With apologies to Carroll and Hofstadter) -m

Creating Applications with Mozilla

Complete text online. -m

HLink as CSS, <meta>, and RDF

HLink is a language for describing links. Other W3C technologies already have the purpose of describing things, so it's interesting to experiment with what that language would look like implemented in other languages.

Defining <img/> in XHTML

HLink: (This is an example from the official specification)

<hlink namespace="http://www.w3.org/1999/xhtml"
       element="img"
       locator="@src"
       effect="embed"
       actuate="onLoad"
       onFailure="warn"/>
<hlink namespace="http://www.w3.org/1999/xhtml"
       element="img"
       locator="@longdesc"
       effect="new"
       actuate="onRequestSecondary"/>
<hlink namespace="http://www.w3.org/1999/xhtml"
       element="img"
       locator="@usemap"
       effect="map"
       actuate="onLoad"/>

CSS:

img {
  arc-define: {
    locator: attr(src);
    effect: embed;
    actuate: onLoad;
    onFailure: warn;
  }
  arc-define: {
    locator: attr(longdesc);
    effect: new;
    actuate: onRequestSecondary;
  }
  arc-define: {
    locator: attr(usemap);
    effect: map;
    actuate: onLoad;
  }
}

MFG:
(This defines the URI http://www.w3.org/1999/xhtml/elements#img to mean "all <img> elements everywhere)

<meta about="http://www.w3.org/1999/xhtml/elements#img" property="hlink:arc">
  <meta property="hlink:locator>@src</meta>
  <meta property="hlink:effect>embed</meta>
  <meta property="hlink:actuate>onLoad</meta>
  <meta property="hlink:onFailure>warn</meta>
</meta>
<meta about="http://www.w3.org/1999/xhtml/elements#img" property="hlink:arc">
  <meta property="hlink:locator>@longdesc</meta>
  <meta property="hlink:effect>new</meta>
  <meta property="hlink:actuate>onRequestSecondary</meta>
</meta>
<meta about="http://www.w3.org/1999/xhtml/elements#img" property="hlink:arc">
  <meta property="hlink:locator>@usemap</meta>
  <meta property="hlink:effect>map</meta>
  <meta property="hlink:actuate>onLoad</meta>
</meta>

RDF:

<rdf:RDF
xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'
   xmlns:hlink="http://www.w3.org/2002/url_for_rdflink#"
>
  <rdf:Description rdf:about="http://www.w3.org/1999/xhtml/rdflink#img">
   
    <hlink:arc rdf:parseType="Resource">
      <hlink:locator>@src</hlink:locator>
      <hlink:effect>embed</hlink:effect>
      <hlink:actuate>onLoad</hlink:actuate>
      <hlink:onFailure>warn</hlink:onFailure>
    </hlink:arc>
    <hlink:arc rdf:parseType="Resource">
      <hlink:locator>@longdesc</hlink:locator>
      <hlink:effect>new</hlink:effect>
      <hlink:actuate>onRequestSecondary</hlink:actuate>
    </hlink:arc>
    <hlink:arc rdf:parseType="Resource">   
      <hlink:locator>@usemap</hlink:locator>
      <hlink:effect>map</hlink:effect>
      <hlink:actuate>onLoad</hlink:actuate>
    </hlink:arc>
  </rdf:Description>
</rdf:RDF>

This looks promising. -m

Today's links:
The Recording Industry is Trying to Kill the Goose That Lays the Golden Egg by Dan Bricklin

99.9% of Websites Are Obsolete by Jeffrey Zeldman
-m

Next week: face to face meeting. Yes, all week. Limited net access. -m

Chapter 7, on XML Events and XForms Actions uploaded. -m

XForms a Huge Step Forward for Web Forms

eWeek's Timothy Dyck takes a look at XForms and likes what he sees. -m

Check out my xml.com article: What's Next for HTML? -m

A nice summary of How to write standards-compatible web pages. And it's not even any harder than playing browser favorites. -m

Fragment identifiers for text/plain.

Update: I wrote up a similar idea, except that is works without any parenthesis (bare fragments), and thus can be useful for content-negotiated resources. Unfortunately, it's still only on paper. -m