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

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:
>>>
>>> Comparing relation types case-sensitively (e.g. as in 4.2 Extension
>>> Relation Types) is incompatible with HTML's processing of rel=""; I
>>> would like to request that all relations always be case-insensitive.
>>
>> Is that specific to HTML5? How does HTML5 process rel?
>
> All versions of HTML have been case-insensitive throughout their  
> rel=""
> procesing, as far as I can tell.

How do other people feel about changing extension relation types to be  
compared case-insensitively? It's certainly weird to compare URIs in  
this fashion, but AFAICT this won't break anything as long as authors  
are aware of it.

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

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

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


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

Ah, thank you.

There are many such aspects; e.g., to other applications, it's  
important to know whether spiders should follow a link.

Rather than trying to record all of these different facets in the  
registry, it would be better if there was one place for it that  
defined that application -- whether it's "saving an archive of a Web  
page" or "spidering a resource," with references to registered and  
unregistered relations as necessary.


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

What I imagine will happen is that if someone wants to specify a new  
relation that has an effect on browsers, they'll write a specification  
for it and define the new relation, as well as any considerations for  
a particular application (e.g., web browsing) that it implies. Whether  
that "updates" HTML5 depends on how you structure the spec, allow  
extensibility, etc.

At any rate, doesn't HTML5 already define what to do when a relation  
type with unrecognised or inapplicable semantics is encountered? If  
so, that should cover this.


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

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.

Alternatively, the CSS spec itself (or an adjunct to it, since it's  
already out there) could explain its applicability (when the type is  
text/css, of course).

It doesn't make any sense to put it in the Link header section,  
because HTTP headers have nothing to do with the specific application  
or ANY of the media types here.


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


>>> 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 like to request some guidance on what HTML5 would have to do
>>> to be compatible with this draft, and what benefits would come from
>>> it. There are clear benefits to the Link: header section, assuming
>>> that how it fits into the general Web platform is defined (as
>>> requested above). But how does the registry fit into the  
>>> RelExtensions
>>> registry for HTML5? How should they interact?
>>
>> If HTML5 chooses to adopt this framework, it would need to:
>>  1) Define the syntax for serialising and parsing links in HTML5,  
>> using the
>> terms defined in the draft (see Appendix C), and
>
> Does what HTML5 already says on the matter satisfy this?
>  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.
>  3) Define how undefined / unrecognised relations are to be handled  
> (with a
>> heavy bias towards must-ignore), and
>
> Ok.
>
>>  4) Optionally, define additional registered and/or extension link  
>> relations.
>
> Ok. Is what HTML5 already has for this adequate?

I'll address these in a separate e-mail, as I've already taken long  
enough to answer this, and it will take some digging to come up with  
helpful suggestions.


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


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

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.

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?


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

Received on Wednesday, 16 September 2009 05:38:50 UTC