Re: Link Relationship for Moving Down a Hierarchy

On Sun, Jan 16, 2011 at 12:11 AM, Ian Hickson wrote:

> what software are you hoping will act on this, and what are
> you hoping it will do with it?

Scripts which parse the @href and @src attributes in a site, compile a
graph from them, and use that graph to inform various things. Some
examples:

* Automatically generate tables of contents
* Give lists of file dependencies to make moving pages easier
* Show pages needing integration, what wikipedia calls "orphans"

This code is already written, and is using rev="up" as part of the
first example in the list above. Since @rev has been removed, I now
need an alternative. I do not mind which alternative, as long as it
has consensus and can be parsed.

A table of contents generated by this code may be exhaustive, showing
every document in a directory or even site, or restricted in some way.
One useful restriction is to not include documents, not necessarily
just HTML pages, which are already linked to in certain ways.

If a document is included in an HTML page with @src, it makes sense in
this mode to exclude it from the table of contents. Sometimes I
exclude @href documents of certain type, for example all python files
that are linked to from webpages.

In the case of rev="up", I am expressing that the page linked to is a
child, rather than for example a sibling, of the present page. This
can't be done with rel="up" on the referenced page for at least two
reasons:

* Some of those pages are archived content, like /TR/ files on w3.org
* When a parent doc is found, the child can be skipped (a code optimisation)

There may be other sensible reasons that I haven't thought of.

Since I was using rev="up", the natural thought for an HTML5
compatible replacement was rel="down". I looked at the link
relationships specification and wiki entry to see if there were any
existing proposals meeting this. There were not. The "subresource"
relation in the wiki is closest, but that is not for example allowed
on <a> elements.

Considered replacements include:

* Reinstating @rev
* Relationships such as "down", modified "subresource", or "covers"
* A new custom x- or data- style relationship
* Some kind of @data- attribute value
* A custom link @class value
* Suggestions from others

Again, I'm not fussed about the shape of the solution, as long as
there is one. I write this message understanding the tension between a
single developer who wants some feature, and a specification which
must be based in a universal consensus abstracting a feature set
across the widest possible number of use cases.

-- 
Sean B. Palmer, http://inamidst.com/sbp/

Received on Sunday, 16 January 2011 12:25:35 UTC