Comments on HLink

Greetings,

Some comments on the HLink draft: 

0. Good work!

1. I've played with various syntaxes [1]. My conclusion is that RDF would be
the best choice, since RDF is all about describing things, which is exactly
what HLink does. Having a recognized, machine-readable syntax with strong
tools support is also important.

Here's an example of what RDF syntax would look like:
(this corresponds to example 2.3 #2 in the spec)

<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:is_link rdf:parseType="Resource">
      <hlink:locator>@src</hlink:locator>
      <hlink:effect>embed</hlink:effect>
      <hlink:actuate>onLoad</hlink:actuate>
      <hlink:onFailure>warn</hlink:onFailure>
    </hlink:is_link>
    <hlink:is_link rdf:parseType="Resource">
      <hlink:locator>@longdesc</hlink:locator>
      <hlink:effect>new</hlink:effect>
      <hlink:actuate>onRequestSecondary</hlink:actuate>
    </hlink:is_link>
    <hlink:is_link rdf:parseType="Resource">   
      <hlink:locator>@usemap</hlink:locator>
      <hlink:effect>map</hlink:effect>
      <hlink:actuate>onLoad</hlink:actuate>
    </hlink:is_link>
  </rdf:Description>
</rdf:RDF>

It's pretty namespace-heavy, but since this gets written once per markup
language, that's a reasonable trade-off. This is what RDF was born to do.

I will use RDF syntax throughout the rest of this message.


2. Make hlink:definition optional for well-known languages.

Exactly as a link to CSS is never required in XHTML, a link to HLink
shouldn't be either. Individual markup languages should be able to define a
'default HLink document' (parallel to a default stylesheet) that sets
expectations for implementations. For pure-play generic XML,
hlink:definition is still useful.


3. A common scenario is to have an element that can either contain inline
content, or remote content. It should still be considered a link in either
case. (either local->local, or local->remote)

Something like:

<hlink:locator>@src</hlink:locator>
<hlink:fallback>content</hlink:fallback>

which means "use the value of the src attribute if it's there, otherwise the
link goes to the element content". In this case, it is important to
distinguish between a failed attempt to access the remote resource, and the
complete absence of the src attribute.

Provide better names as appropriate. :-)


4. ID/IDREF is also a form of linking, albeit quite messy in current XML
technology.

If HLink  provided a way to describe ID/IDREF relationships, it might pave
the way for a cleaner path.


5. Consider using Schema adjuncts or some other way of associating HLink
with a document.

For instance:

<xs:attribute name="src">
  <xs:annotation>
    <xs:appinfo>
      <hlink:is_link rdf:parseType="Resource">
        ...
    </xs:appinfo>
  </xs:annotation>
</xs:attribute>

Doesn't score well on the verbosity department, but again, since this is
something that only needs to be done once per markup language, it's still a
good trade-off. Another possibility is RDDL, or whatever ends up at the end
of the namespace dereference.


6. Don't use magic attribute values (@)

Arjun Ray had some good comments along these lines. Within an RDF framework,
another answer is just to introduce separate properties for has-value and
attribute-has-value.

Example:
<hlink:locatorAttribute>src</hlink:locator> <!-- the '@' no longer needed
-->
vs.
<hlink:locator>http://www.example.com/markup</hlink:locator>

This does introduce the possibility of conflicting statements, but that is
always a possibility in RDF, or any way of describing things.


7. It would be an interesting exercise to see if HLink can describe
processing instructions, notably xml-stylesheet. This could be done with
another RDF property.


8. A common complaint with XLink is that the show (and to an extent actuate)
values are presentational in nature. HLink should replace these two values
with a single value that describes the _meaning_ of the link, which can then
be "shown" and "acutated" or styled with CSS in whatever way makes sense for
the local environment.

A potential (and likely incomplete) list of possible values for this
attribute is:
* X includes Y (XInclude)
* X renders Y (<img>)
* X is-a document unique ID (id)
* X refers to a document unique ID (idref)
* X annotates Y (link to RDF)
* X hyperlilnks to Y (<a>)
* X submits to Y (<form>)
* X is titled by Y (<title>)
* X is described by Y (xsi:schemaLocation)
* X is styled by Y (xml-stylesheet, etc.)
* X is transformed by Y

Some of these (<title>) demonstrate things not currently possible in generic
XML.

It gets more interesting if you consider an XML Events-based processing
model. I can provide further details if anyone's interested.


9. Going down the path of greater generality, it should also be possible to
better describe exactly where the two (or more) ends of the link are
anchored. XArc [2] is an excellent example.


10. Going even further, it should be possible to describe multi-element arcs
and linkbases.
For a large number of such advanced cases, XLink provides the ideal syntax.
The idea here is to eventually somehow combine things into a single
specification, taking the best ideas from both XLink and HLink.

Thanks,

.micah

[1] http://dubinko.info/blog/2002_09_08_archive.html#81571209
[2] http://www.jfinity.com/xarc/spec-current/

Received on Wednesday, 18 September 2002 18:19:45 UTC