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

On Wed, 16 Sep 2009, Mark Nottingham wrote:
> On 30/08/2009, at 12:23 PM, Ian Hickson wrote:
> > On Thu, 20 Aug 2009, Mark Nottingham wrote:
> > > On 31/07/2009, at 10:20 AM, Ian Hickson wrote:
> > > > I think for the best compatibility with legacy implementations, 
> > > > the spec should say that there must only be one occurance of each 
> > > > attribute, and that multiple link types in one Link: header should 
> > > > be listed in one rel="" attribute. (That is, only allow rel="a b", 
> > > > not rel=a;rel=b.)
> > > 
> > > Do you have data to back this up?
> > 
> > As far as I can tell, Mozilla only supports one of each attribute. Are 
> > there UAs that support more?
> 
> How did you test that?

http://www.hixie.ch/tests/adhoc/http/link/009.html

Opera also only supports one of each attribute.


> > 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.
> 
> That's an artefact of their syntax (SGML and XML-based, respectively); 
> do you expect people to use the same parsers?

I expect implementations to use the same internal APIs, and those APIs are 
designed with the expectation of a single value for each attribute. For 
example, look for nsContentSink::ProcessLink() in the Mozilla codebase.


> > > 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 think Julian covered why it's necessary to have this.

Do you mean here?:

   http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0634.html

If so, I do not find his reasoning convincing.


> As far as how it works in UI -- present the most appropriate title based 
> upon the users preferences.

Could you give a concrete example of a Link: header that uses multiple 
titles in this way and describe what you think the ideal UI for that 
example would be?

I continue to fear that this feature will not ever be properly 
implemented.


> [snip various answers saying that various things shouldn't be registered 
> in the registry but that each registered link type should have a 
> corresponding specification that defines how the link type works in all 
> the situations that might support it]

I think this basically makes the registry worthless. At least for HTML5, 
there are several aspects that we need to have in a machine-readable 
fashion for each link type, including:

 - whether the link type is allowed on <link>
 - whether the link type is allowed on <a> and <area>
 - whether the link type is a hyperlink or references an external resource

If the link registry isn't going to be providing this, then it's not 
really solving the problems for which HTML5 needs a registry.

I guess to avoid name clashes the HTML5 link registry can require that the 
link type be registered with your registry and that the semantics defined 
for HTML5 be consistent with those referenced by the specification given 
in the registry.


> > Why should HTML5 define how rel=stylesheet of a CSS file applies to an 
> > XML document? That doesn't sound right at all.
> 
> My understanding was that HTML5 is not only defining the HTML syntax, 
> but also the model for what a "web browser" is and does; if that's the 
> case, it's one place to put it.

That is not the case. HTML5 defines HTML, and how all classes of HTML 
processors, whether search engines, editors, or anything else, are to 
process HTML.

It does not define how an XML+CSS processor is to handle an HTTP header.


> > 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.
> 
> This leads to a situation where every time someone comes up with a new 
> application of linking, they have to update Atom, HTML, the Link spec 
> and whatever other serialisations are defined; that seems unworkable for 
> a variety of reasons (multiple processes, document updates, etc.).

If someone comes up with a new way to link a style sheet to a document, 
then yes, I expect them to define how this works with the technologies 
that they have then affected.


> > > > 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.
> 
> Do you have concrete suggestions for the IANA process to be used?

I would suggest that the IANA host a wiki that anyone can edit.


> > > > 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?
> > > 
> > > 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?
> 
> No. As far as it goes, it doesn't work at all at the moment, AIUI; i.e., 
> a UA is free to ignore the relation type and treat it link any other 
> link (which is as it should be). I'm not sure what the automated cases 
> for it are.

Does it not have a specification that defines this?


> > 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.
> 
> People will want to do different things with relations like "prev," 
> "index" and "alternate"; not all link relations are purely functional 
> (indeed, most should not be) and there will be unintended reuse of them 
> for things we can't foresee.

I don't think there's much point having a single registry then. We should 
just have different registries for each linking mechanism, if that's going 
to be the practical scope of the registry anyway.


> Take, for example, the "duplicate" relation type currently being 
> discussed; while it's immediately useful for MetaLink, there are many 
> other potential uses for it, and the client behaviour with each is 
> potentially different.

What happens when it's defined one way for Atom, and another way for HTML, 
and then each group wants to extend their processing to HTTP linking when 
used with SVG?


> BTW, I was wandering through 
> <http://www.w3.org/TR/html5/history.html#linkTypes> and found "sidebar." 
> Why use a link relation type here when the target attribute is already 
> available?

The target="" attribute would create a new window instead of gracefully 
falling back to using the current window like rel="".

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 16 September 2009 07:39:10 UTC