WD-hlink-20020913 comments (wrapped)

(I didn't realize that the archived version wouldn't wrap the paragraphs, so I'm sending this copy, which will be easier to read from the archive.)

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 15:41:22 UTC