Re: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard

On Sun, Aug 30, 2009 at 4:23 AM, Ian Hickson <ian@hixie.ch> wrote:

>
> As far as I can tell, Mozilla only supports one of each attribute. Are
> there UAs that support more?
>
> Given that HTML and Atom only allow one of each attribute, I think we're
> far less likely to have bugs if we say that all but the first occurrance
> of each attribute is just ignored.
>

Sounds good.


> > I'm concerned that this would disallow internationalisation of title,
> > for example (e.g., you couldn't express both an english and a spanish
> > title for a link).
>
> That sounds like one of those things that looks good on paper but doesn't
> really ever translate to implementations. Are we really expecting authors
> to provide multiple titles per link? How would that work in UI?
>

I'm working on the OGF's Open Cloud Computing Interface
(OCCI)<http://www.occi-wg.org/>and have been making extensive use of
links in Atom, HTTP and possibly HTML.
Here we have software clients (think desktop managment interfaces) which
will want to display some/all links in the local language - so either all
the links are advertised in every response or we use content negotiation to
return the links in the local language only.

One of the grey areas we ran into related to the length of the links,
especially when concatenated into a single Link: header - what will proxies,
firewalls and user agents do when they find a 2k header containing 150
languages?


> > > I would like to request that each link type be defined as either being
> > > a hyperlink or an external resource link, as defined in HTML5, and
> > > that this be added as one of the things that must be defined in the
> > > registry.
> >
> > I'm not sure what an "external resource link" is, could you please
> > remind me?
>
> When you mirror a page ("Save As ... Complete" or "Save As ... Archive"),
> external resource links are those that are fetched and included with the
> source document, whereas hyperlinks are those that are considered to be
> separate.
>
> A style sheet, for instance, is an external resource link. A regular <a
> href=""> is just a hyperlink.
>

That's an interesting question - consider a 10k HTML rendering of a virtual
machine with a link to a 40GB disk image.


> > > Similarly, the registry should define whether or not link relations
> > > are allowed at the document level (<link rel>, Link:) and at the
> > > phrasing level (<a rel>, <area rel>). Some types in HTML5 only apply
> > > to one or the other.
> >
> > That's a job for HTML5 as an application of the relations, not the
> > registry.
>
> So every time someone adds something to the registry, we have to update
> HTML5 to say whether that keyword can be used with HTML?
>

I'm still in favour of a centralised "Link Relations" registry if that can
be made to work, with only new link relations defined in any given standard.
This sounds like a fine source for interoperability problems, particularly
when moving between formats (e.g. rendering a feed). Standards writers could
use the "static" IANA and "dynamic" WHATWG registries as normative and
informative references respectively.


> > > Ideally, I would like the Link: header section to more clearly define
> > > how some of the keywords defined in the spec should actually be used.
> > > For example, how should the rel=stylesheet keyword affect the CSSOM?
> > > Where do resources imported in this way fall in the CSS cascade? How
> > > should it affect documents with MIME types like text/plain? Do
> > > rel=icon links interact with those specified in the document? If so,
> > > where should they be considered as falling in terms of tree order?
> >
> > Again, a job for HTML5.
>
> Why should HTML5 define how rel=stylesheet of a CSS file applies to an XML
> document? That doesn't sound right at all.
>
> It's the linking mechanism, in this case the Link: header, that should
> define how it works, just like how HTML5 defines how <html:link> works in
> XML, or how the XML Style Sheet PI spec defines how <?xml-stylesheet>
> works in XML.
>

I tend to agree that there's some benefit in saying "when we're talking
about style sheets we use the 'stylesheet' relation" and leaving each
specification to describe *how* it is used. Otherwise HTML can effectively
"reserve" the identifier and XML/XSLT has to come up with their own -
despite the fact that both have different MIME types.


> > > I would like to request that the registration mechanism be made
> > > significantly simpler than the one described in the spec. For example,
> > > a simple mechanism could be just to edit a wiki listing all the
> > > extensions.
> >
> > In the IETF, IANA is the mechanism for managing registries like this.
>
> Regardless of who manages the registry, I would like to request that the
> registration mechanism be made significantly simpler than the one
> described in the spec.
>

I tend to agree with this - provided the explanation is sensible (e.g.
'stylesheet' identifies document(s) specifying style information and 'up'
identifies the parent resource) it should be accepted as a generic rule,
with each standard then specifying the details for their specific
implementation.

Again referring to OCCI, virtual machines can have parents (think
snapshots/clones) - why would I want to define a new standard-specific
relation for this when a perfectly good one already exists.

>   2) Associate concrete behaviours with the general semantics of the
> > registered link relations it finds interesting, and
>
> I don't understand how we can do that since most of the link relations
> that people will want to use with HTML5 haven't even been thought of yet.
>

A wiki is definitely a good place for relations that are not defined by an
accepted, stable standard even if just to avoid clashes during
experimentation, and the relations themselves should be able to come from
anywhere (they will anyway so the registry may as well reflect reality or it
will be ignored).

For example, if Google Wave were to define a 'deltas' relation that
reflected a connection or feed of changes to the document then generic
wording could be entered independent of any particular specification
(perhaps with an informative reference back to the source).


> > > The "up", "first", "last", and "payment" types are woefully
> > > underdefined. What is the expected UA behaviour when discovering a
> > > link with rel=payment? What are the authoring requirements? What are
> > > the implementation requirements?
>

up: parent document
first: document preceding all others
last: document coming after all others


> > I'd agree that "payment" is ill-defined, but most of the questions you
> > ask need to be answered (once again) in the context of a particular
> > application of linking, not by the registry.
>
> So how rel=payment works will differ for Atom and for HTML?
>

Quite possibly - perhaps an Atom Payments standard will be written to define
a machine interface for processing payments while for HTML a shopping cart
user interface is more appropriate. For OCCI we may want to have some
complex brokering/least cost routing system that doesn't fit with either.

A payment is a payment is a payment - given multiple standards create
contention for a very confined namespace (the english language) we either
need to allow for overlap with standards defining their own contexts, deal
with ugly relations (like 'atom-payment') or accept that the registry will
be ignored.


> It seems pointless to have a registry at all, if the behaviours are scoped
> to each use of the term, rather than being related to the term.
>

That may be true. I guess my gripe is that relations should be generic -
more derived from the dictionary than standards documents.

Sam


> On Wed, 19 Aug 2009, Eran Hammer-Lahav wrote:
> >
> > Combining rel values is an awful idea. If someone wants 'up up up' they
> > should define a rel value of it like up-n (up-1, up-2, etc.). Being able
> > to indicate multiple relation types for a given link is an important
> > part of the link architecture and clients should not need to look for
> > how rel values change the meaning of each other.
>
> We're past this already with rel="alternate stylesheet", and to be honest,
> I don't really see what's that wrong with it, except for the overloading
> of the keyword "alternate".
>
> The main advantage of rel="up up up" rather than rel="up3" is that for UAs
> that only need to know that the link is an "up" and don't care about how
> far "up" it goes, the keyword automatically works -- you don't have to do
> rel="up up3". Also, it means that we don't have to register an infinite
> number of keywords for all possible depths.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>