W3C home > Mailing lists > Public > www-html-editor@w3.org > October to December 2002

WD-hlink-20020913 comments

From: Bob DuCharme <bob@snee.com>
Date: Tue, 22 Oct 2002 10:35:20 -0400
To: www-html-editor@w3.org
Message-ID: <20021022103520.A24400@snee.com>


In general, I agree that people aren't using XLink the way the XLink WG had hoped--in fact, they're hardly using it at all--and the cause of this should be explored and addressed. As a special-purpose, ad hoc implementation of architectural form-like mapping that follows XLink in some places, deviates in others, and leaves the relationship up in the air in far more places, I don't think that HLink in its present form does a good job of addressing XLink's problems. I realize that it's only a first cut, but its presentation of the hlink element is vague and fuzzy, and its presentation of the hlinks element is even worse. 

As I understand it, HLink is for people who find XLink to be too complex. If that's the case, then the HLink Note's definition and use of terms should be at least as clear as that of the XLink. It should either have a definitions section or explicitly say that it's working from the XLink definitions. For example, what is a link? What is a hyperlink? Are they any different? (The term "hyperlink" is used twice in the abstract, and nowhere else.) The varying scope of what people mean by "(hyper)link" is a leading cause of all the confusion about the relationship between linking, hyperlinking, XML, (X)HTML, and the domains being modeled and presented using these technologies. If web developers for whom XLink is too much are supposed to use this specification, there are a lot of terms in the HLink Note that will only make vague sense to them. 

One example: what do forms (effect="submit") have to do with linking? (Is it that clicking on a "Submit" button leads you to a different screen? If this is a link, then linking can have side effects, and the role of the side effects must be accounted for in the generalized definition of a link.) If "linking" were clearly defined, I would hope that this relationship would be obvious in the description of effect="submit".

hlinks element: "The hlinks element exists only to be a root element for a document containing only hlink elements." Perhaps the Note could include more than this solitary sentence and a content model of hlink+ about this element. Where does the hlinks element go? In a document, yes. How does that document relate to any processing that takes advantage of what's declared in the hlinks document? The "documentation" of this element in the appendixes for the RELAX NG schema,

  <define name="hlinks">
    <a:documentation>
       hlinks element
    </a:documentation>

and W3C Schema,

  <xs:element name="hlinks">
    <xs:annotation>
      <xs:documentation>
      hlinks element
      </xs:documentation>

are worthless. Compare the following:

  <xs:element name="foobar">
    <xs:annotation>
      <xs:documentation>
      foobar element
      </xs:documentation>

What does this tell you about the purpose and use of the foobar element?


2.2 The hlink element's "element" attribute: 'If this attribute has the special value "*" then the rest of the attributes describe all suitable elements in the namespace (as defined by a DTD or schema)' What does it mean by "suitable"?

actuate attribute: "This attribute specifies the manner that the link should or can be actuated." And the foobar element specifies how the link should be foobarred. What does it mean by "actuate"? Descriptions of other hlink attributes in this section explicitly refer to the XLink definitions so that people know what they're for; this should do so as well (http://www.w3.org/TR/2001/REC-xlink-20010627/#actuate-att) or provide its own definition in the context of XLink. 

"that itself has a descriptor to a link" The meaning of "descriptor" is far from self-evident here.

"such as XHTML's <a> element" In XHTML, "<a>" is not an element. It's a start-tag, the first delimiter of an element. When text can't switch to courier to represent an element name, people sometimes use the angle brackets to show that they're referring to an element name, but this further confuses the many beginners who don't know the difference between elements and tags. (The XML FAQ doesn't include the question "What's the difference between a tag and an element" because the question isn't Asked Frequently enough. Instead, the answer to this question was snuck in under a slightly different question--see http://www.ucc.ie/xml/#makeup.)

onRequestSecondary: Yes, a link to more than one destination is a reasonable scenario, but why does it have to be no more than 2? Why not have an onRequestTertiary? Of course, this latter question is rhetorical, because the answers are obvious: limiting it at 3 is not a good idea either, and overloading the element with attributes is a bad idea, and imposing an ordered relationship on the link destinations is not something to take for granted that people want. Unfortunately, all these arguments apply to onRequestSecondary as well.

arcrole: "See Xlink for description." XLink spec: "The arcrole attribute corresponds to the [RDF] notion of a property, where the role can be interpreted as stating that "starting-resource HAS arc-role ending-resource." HLink on "role": "This attribute gives information to the user agent about the role the link plays. [[More]]" The "more" should distinguish it from arcrole. Since HLink never defines "link," I'll go with the XLink definition (and note that XLink defines hyperlink differently): "an explicit relationship between resources or portions of resources." To restate my HLink role vs. arcrole question: How is the role played by an explicit relationship between resources different from the relationship defined by an RDF predicate between its subject and object resources? 

thanks,

Bob DuCharme          www.snee.com/bob           <bob@  
snee.com>  "The elements be kind to thee, and make thy
spirits all of comfort!" Anthony and Cleopatra, III ii
Received on Tuesday, 22 October 2002 11:28:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:17:43 GMT