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

On 16/09/2009, at 5:44 PM, Ian Hickson wrote:
>
>>> 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.

You're proving my point; Mozilla has nsContentSink::ProcessLinkHeader,  
which calls nsStyleLinkElement::ParseLinkTypes() (as does ProcessLink 
()).

That code does happen to only allow one rel value, but that's a bug,  
as the current specification of the Link header in RFC2068 and earlier  
clearly allow multiple rel attributes, and fixing it is a matter of a  
line or two.

Nevertheless -- how do other people feel about restricting to one rel  
attribute in the Link header? Looking back at 2068, the BNF implicitly  
allows multiple rel values, but it isn't explicitly addressed in the  
prose, so Ian does have a point -- you could see it either way.


>> 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?

    Link: </TheBook/chapter6>; rel="last"; title*=UTF-8'de'letztes 
%20Kapitel; title*=UTF-8'en'final%20chapter

One example of a UI -- if it chooses to use the title instead of the  
URL for displaying the link (e.g., in a toolbar dedicated to showing  
links) would use the first title* if the users configured language was  
German, and the second if it were English.


> [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.

Just so I understand, a straw-man use case: if I wanted to define a  
HTML5 extension that modified the page by fetching chunks, implemented  
in JS (e.g., something functionally similar to <http://www.mnot.net/javascript/hinclude/ 
 >), I could register a relation type for those links that included  
the fact that they're external resources, so that browsers would  
automagically download them as well when a user does "save as"?

If that's in-scope, I guess it's nice-to-have, but it seems like a lot  
of trouble. Won't most such extensions actually require browser  
changes, thus reducing the value of having this information machine- 
readable? Do you intend for this machine-readable information to be  
used at compile time, or runtime?

Also, what's the value of having the information about where a link is  
allowed machine-readable? Won't it simply be ignored if it's not  
understood and in a valid place?


> 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.

Yes, that's one approach that could be taken.


>>> 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.

OK. The point is that some XML+CSS spec needs to define this behaviour.


>>> 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 point of having a registry is to act as a gateway, to assure  
appropriate review and coordination. Allowing anyone to edit the  
contents removes these benefits; people wanting to mint new relations  
without coordination or even review can do so by using extension  
relations.


>>>>> 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 doesn't, because the Atom registry policy is first-come-first- 
serve; i.e., it operates like a wiki, where anyone can put something  
into it, without review / appropriate levels of documentation / etc.


>> 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?

Why do you want to constrain implementations of even one of these  
formats to treat "duplicate" in the same way (much less across  
formats)? All the link relation is doing in this case is indicating  
that the linked resource has certain attributes (sharing  
representations with the context IRI); there is no "right" behaviour  
in handling this, and its presence doesn't imply that the client has  
to implement any particular behaviour, handling or protocol.


>> 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="".


Given that the intent of a sidebar is to open it in a different pane  
without replacing the current content, is that a bad thing?


--
Mark Nottingham     http://www.mnot.net/

Received on Thursday, 17 September 2009 05:15:02 UTC