Subject: anchor parameter, was: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard

From: Julian Reschke <[email-masked]>
Date: Sun, 02 Aug 2009 09:18:42 +0200

Ian Hickson wrote:
> ...
> Unless there are really strong use cases, I think that the anchor= 
> attribute should be dropped. In practice, implementations today ignore 
> that attribute, which would mean that, e.g., a rel=stylesheet;anchor=a 
> link would fail to have the "right" effect. If it is kept, then the right 
> behaviour for how this should integrate with style sheet linking should be 
> defined in great detail.
> ...

Could you please elaborate what the "right" effect is, and how current 
implementations fail for that?

It appears to me that anchor is not relevant for every single link 
relation, but that doesn't mean it's not useful at all.

BR, Julian

---

From: Ian Hickson <[email-masked]>
Date: Sun, 2 Aug 2009 09:04:41 +0000 (UTC)

On Sun, 2 Aug 2009, Julian Reschke wrote:
> Ian Hickson wrote:
> > ...
> > Unless there are really strong use cases, I think that the anchor= attribute
> > should be dropped. In practice, implementations today ignore that attribute,
> > which would mean that, e.g., a rel=stylesheet;anchor=a link would fail to
> > have the "right" effect. If it is kept, then the right behaviour for how
> > this should integrate with style sheet linking should be defined in great
> > detail.
> 

Well unless I'm mistaken, if we have a resource A that has:

   Link: <B>; rel=stylesheet; anchor=C

...then that means we have a link:

   C - stylesheet - B

...which means that applying the style sheet to A would be wrong. Yet that 
is what UAs that support Link: would presumably do.

> relation, but that doesn't mean it's not useful at all.

I don't see how it can't be relevant... if the link relation is between 
two resources, then acting as if it was a relationship between others 
seems wrong.

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

---

From: Julian Reschke <[email-masked]>
Date: Sun, 02 Aug 2009 12:47:06 +0200

> is what UAs that support Link: would presumably do.

Of the five UAs I checked, two seem to implement the Link header. Both 
fail to consider the anchor.

To make Link headers useful in processing by HTML user agents, lots of 
additional implementation work is needed anyway; so I don't see this as 
a big problem.

That being said, it probably would be good if the spec gave an example 
that anchor can be more than a fragment identifier, and thus recipients 
need to handle it -- it's not optional.

> two resources, then acting as if it was a relationship between others 

Right; it *is* relevant if it's more than a fragment identifier, and it 
would be good if the spec stated that clearly.

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 20 Aug 2009 09:55:29 +1000

[ moving follow-up to httpbis ]

Sorry for the delay, Ian. Responses below.

On 31/07/2009, at 10:20 AM, Ian Hickson wrote:

> In general, I don't really understand what problem this draft is  
> trying to
> solve. A clearer statement in the abstract or introduction explaining
> _why_ a common registry is a good thing would be very useful.

I'll take a stab at this in the next rev.

> It might also be worth considering separating the Link: header and the
> registry into two different specifications. This would also help  
> clarify
> how a specification should refer to the registry.

How do others feel about this? I'm disinclined to do so unless there's  
considerable value in it. I could see adding a new appendix suggesting  
things that new applications of linking that use this framework,  
however; would that be useful?

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

> The Link: header has a "rev" attribute. I would recommend dropping  
> it for
> consistency with HTML5; we discovered in examining typical usage that
> people generally didn't understand how to use rev="", and it is  
> redundant
> with rel="" anyway. If it is kept, then please define how it works.
> Allowing something but leaving it undefined is the worst of both  
> worlds.
> (The ideal would be to define how it works but not allow it, IMHO.)

It was included because it's in the syntax of RFC2068, but I agree  
that it's not desirable to perpetuate it. How do people feel about  
further removing it (i.e., it will be an extension, not called out  
explicitly in the syntax)?

> The link relations should better define how to handle interactions  
> between
> multiple link types, so that alternate stylesheet can be well-defined,
> and so that we can define rel="up up up" as in HTML5.

I think the general consensus is that this is bad practice, but if  
HTML5 wants to define semantics around cardinality, it can do so when  
it defines how that relation is interpreted within the scope of its  
application. I.e., mapping "up up up" to specific behaviours is the  
job of HTML5, not the link framework.

It's worth mentioning here that because HTML5 defines both a syntax  
and what is effectively an application of linking (roughly, "web  
browsing"), it needs to define both the syntax for links and the  
behaviours associated with them.

> I recommend dropping the entire bit about profile="" -- while it  
> sounds
> like the right thing to do, in practice almost nobody uses  
> profile="", and
> the attribute has been dropped in HTML5. This is a lot of complexity
> without a particularly compelling use case as far as I can tell.

I think I agree; I'll rewrite to point out that there are multiple  
ways of serialising extension links in HTML4 (e.g., as full URIs, with  
@profile, using the RDFa syntax.

> The spec should clearly say which takes preference if both title= and
> title*= are given. Also, the spec should clearly say which takes
> preference if multiple title=, type=, etc, attributes are given.

Ack.

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

> behaviour for how this should integrate with style sheet linking  

I think that at the very least, it needs to be specified that the  
anchor attribute is not used by default; i.e., specific applications  
of linking need to specify that the anchor attribute is to be used.

I'm also amenable to deprecating or removing it, but would like to  
hear from others about this.

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

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

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

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

> 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
   2) Associate concrete behaviours with the general semantics of the  
registered link relations it finds interesting, and
   3) Define how undefined / unrecognised relations are to be handled  
(with a heavy bias towards must-ignore), and
   4) Optionally, define additional registered and/or extension link  
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.

That said, I think it's worth discussing the relations above to see if  
we can better define them.

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 19 Aug 2009 17:11:55 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Mark Nottingham
> Sent: Wednesday, August 19, 2009 4:55 PM
> 

> > registry into two different specifications. This would also help clarify

Doesn't seem worth the hassle.
 
> explicitly in the syntax)?

We should drop it, again... (not sure why it came back in a previous draft). There is nothing stopping those who want it from giving it a proper definition and defining it as an extension.
 
> behaviours associated with them.

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.
 
> hear from others about this.

Are there any documented use cases for it? If not, I suggest we drop it.

EHL

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 20 Aug 2009 12:13:16 +1000

It seems to me that we could go in a few directions regarding anchor;

1) get rid of it completely; any app that wants to use it can define  
it as an extension (as they would for HTML and Atom, which don't have  
dynamic scopes).

2) restrict it to ONLY fragment identifiers, and make them advisory  
(i.e., a UA can choose to ignore them when displaying a link).

3) specify that it only has meaning when a particular application /  
relation invokes its use (none to date).

So far I'm hearing that #1 or #2 is probably the right approach. I  
don't see how we can mandate it.

Thoughts?

On 02/08/2009, at 8:47 PM, Julian Reschke wrote:

> Ian Hickson wrote:
>> ...
>>> Could you please elaborate what the "right" effect is, and how  
>>> current implementations fail for that?
>> ...which means that applying the style sheet to A would be wrong.  
>> Yet that is what UAs that support Link: would presumably do.
>
> Of the five UAs I checked, two seem to implement the Link header.  
> Both fail to consider the anchor.
>
> To make Link headers useful in processing by HTML user agents, lots  
> of additional implementation work is needed anyway; so I don't see  
> this as a big problem.
>
> That being said, it probably would be good if the spec gave an  
> example that anchor can be more than a fragment identifier, and thus  
> recipients need to handle it -- it's not optional.
>
>> I don't see how it can't be relevant... if the link relation is  
>> between two resources, then acting as if it was a relationship  
>> between others seems wrong.
>
> Right; it *is* relevant if it's more than a fragment identifier, and  
> it would be good if the spec stated that clearly.
>
> BR, Julian
>
>
>
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 20 Aug 2009 12:47:34 +1000

> In the IETF, IANA is the mechanism for managing registries like this.

BTW -- to be clear, the current intent of the draft is that most  
relations -- and indeed all ones that are application or format  
specific -- will be extension relations; that is, most people who want  
to define a relation will be using URIs (although syntactically they  
may be different; e.g., RDFa in XHMTL).

This is a marked change from the previous approach, where the URI form  
(in Atom) was largely ignored, and people registered relations with a  
very low bar (giving us some with dubious value, and/or difficulties  
in knowing how to support them).

---

From: Sam Johnston <[email-masked]>
Date: Thu, 20 Aug 2009 09:50:45 +0200

On Thu, Aug 20, 2009 at 1:55 AM, Mark Nottingham <[email-masked]> wrote:

> things that new applications of linking that use this framework, however;
> would that be useful?
>

I would try to keep them separate as much as possible - the Link: header
will be long-lived compared to the bootstrapped registry and people should
know well to refer to the "real" registry (and have the benefit of seeing
how to reference it). Is it possible to mark the section to be removed on
publication? If the pertinent information will be captured by IANA anyway
then that would seem to be the preferred option - otherwise it's just cruft.

>> Relation Types) is incompatible with HTML's processing of rel=""; I would

I would tend to agree with this, especially given relations should as much
as possible be generic IMO (e.g. "update" rather than "TwitterTweet") with
the type adding specificity if required. Other semantics (such as that it is
a space separated list) should also be synchronised.

>
>  The Link: header has a "rev" attribute. I would recommend dropping it for
>> people generally didn't understand how to use rev="", and it is redundant
>> Allowing something but leaving it undefined is the worst of both worlds.
> It was included because it's in the syntax of RFC2068, but I agree that
> it's not desirable to perpetuate it. How do people feel about further
> removing it (i.e., it will be an extension, not called out explicitly in the
> syntax)?
>

I would prefer to see it removed as if it's there people will [ab]use it [
http://www.mnot.net/blog/2009/04/14/rev_canonical_bad] and we should, as
much as possible, remain in sync with HTML5. It's unfortunate that abstract
link relations haven't been defined centrally and referred to by specs like
Atom and HTML - perhaps it's too late for that now.

>  The link relations should better define how to handle interactions between
> I think the general consensus is that this is bad practice, but if HTML5
> wants to define semantics around cardinality, it can do so when it defines
> how that relation is interpreted within the scope of its application. I.e.,
> mapping "up up up" to specific behaviours is the job of HTML5, not the link
> framework.
>
> It's worth mentioning here that because HTML5 defines both a syntax and
> what is effectively an application of linking (roughly, "web browsing"), it
> needs to define both the syntax for links and the behaviours associated with
> them.
>

Again coming back to the point about links being defined centrally and
shared across specifications. I tend to agree that this specific example
("up up up") is ordinary and adds a good deal of unnecessary complexity to
implementations (that is, I strongly oppose it). It appears to be only
really relevant for indicating ancestry and then probably only to 2 or 3
generations so "parent", "grandparent" etc. or indeed "up2" "up3" etc. could
work better. In any case this particular example can be resolved by
following the chain. Perhaps this is something worth considering for HTML 5
as well as this represents a deviation.

>> preference if multiple title=, type=, etc, attributes are given.

+1

>
>  I think for the best compatibility with legacy implementations, the spec
>> should say that there must only be one occurance of each attribute, and
> Do you have data to back this up? 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).
>

If that is indeed the case I'd rather break legacy to provide for future
internationalisation.

> I think that at the very least, it needs to be specified that the anchor
> attribute is not used by default; i.e., specific applications of linking
> need to specify that the anchor attribute is to be used.
>
> I'm also amenable to deprecating or removing it, but would like to hear
> from others about this.
>

Unless I've missed something, most applications that need to refer to
specific parts of a document could still do so by embedding the anchor in
the href.

>> 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 reality people are going to [ab]use the relations anyway - raising the
bar (as is no doubt required in this instance courtesy IETF
policy/precedent) runs the risk of giving up any control we may have had
over them. The WHATWG's RelExtensions wiki page [
http://wiki.whatwg.org/wiki/RelExtensions] appears to work reasonably well,
but that said I don't see much harm in having what is effectively an
unofficial testing ground for such things.

>
>  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
>  1) Define the syntax for serialising and parsing links in HTML5, using the
> terms defined in the draft (see Appendix C), and
>  3) Define how undefined / unrecognised relations are to be handled (with a
> heavy bias towards must-ignore), and

I'll leave you two to discuss the details but would strongly support
synchronising the specifications as much as possible. Ideally all
specifications requiring such linking would refer to a common reference but
assuming it's too late for that at this time let's do what we can on both
sides to harmonise them.

In the specific case of the RelExtensions registry it's not really required
except as an informative reference (as experimental/unofficial standards
can/should use URI relations) but as it exists and will likely continue to
exist it should be a superset of the IANA registry and refer back to it
where appropriate.

The bigger risk I see is from standards being treated as mini-registries and
having multiple standards defining a given relation. Standards incorporating
an existing relation should rather include a normative reference to the
original defining standard than re-define the relation. Accordingly,
standards defining new relations should do so discretely.

>
>  The "up", "first", "last", and "payment" types are woefully underdefined.
> 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.
>
> That said, I think it's worth discussing the relations above to see if we
> can better define them.
>

"up", "first" and "last" are likely easily defined. In the simplest sense
"payment" would appear on a product page and give a user agent a HTTP URL
with which to effect a manual payment. The utility in this instance seems
extremely limited, though in combination with a type specifying some
automated mechanism it could well be quite useful. That is, I don't see much
harm in listing generic concepts like "payment" so long as they are, in
fact, generic.

Sam

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Aug 2009 10:01:32 +0200

Sam Johnston wrote:
> ...
>     How do others feel about this? I'm disinclined to do so unless
>     there's considerable value in it. I could see adding a new appendix
>     suggesting things that new applications of linking that use this
>     framework, however; would that be useful?
> 
> 
> will be long-lived compared to the bootstrapped registry and people 
> should know well to refer to the "real" registry (and have the benefit 
> of seeing how to reference it). Is it possible to mark the section to be 
> removed on publication? If the pertinent information will be captured by 
> IANA anyway then that would seem to be the preferred option - otherwise 
> it's just cruft.
> ...

That's not going to work, as the registry entries are supposed to 
reference specifications, in this case (for the old entries), the Web 
Linking spec.

It may make sense to keep the Link registry procedure and the Link 
header in a common document, and just move the re-registration of old 
entries into a separate document, though.

> specific parts of a document could still do so by embedding the anchor 
> in the href.
> ...

The anchor refers to the source, not the destination.

BR, Julian

---

From: Sam Johnston <[email-masked]>
Date: Thu, 20 Aug 2009 10:15:34 +0200

On Thu, Aug 20, 2009 at 10:01 AM, Julian Reschke <[email-masked]>wrote:

> That's not going to work, as the registry entries are supposed to reference
> specifications, in this case (for the old entries), the Web Linking spec.
>
> It may make sense to keep the Link registry procedure and the Link header
> in a common document, and just move the re-registration of old entries into
> a separate document, though.
>

That sounds reasonable - my main concern is that people don't see the
registrations as mini-registries. Another way to resolve this could be to
confine them to an "IANA Considerations" section such that there is no doubt
whatsoever about their purpose (in that case both the registry entry and the
definition would be colocated, which may well not work for other
specifications).

On further consideration it seems useful to have:

   - IANA Registry as a normative reference to official standards
   - WHATWG Registry [or similar] as an informative reference to both
   official and experimental standards (thus providing a mechanism for users
   and editors to locate works in progress and avoid duplication/conflict).

> The anchor refers to the source, not the destination.

Ok so in that case I take no position as I have no applications in mind for
such an attribute.

Sam

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Aug 2009 14:31:37 +0200

Mark Nottingham wrote:
> 1) get rid of it completely; any app that wants to use it can define it 
> as an extension (as they would for HTML and Atom, which don't have 
> dynamic scopes).
> 
> So far I'm hearing that #1 or #2 is probably the right approach. I don't 
> see how we can mandate it.
> 
> Thoughts?
> ...

WRT 1) that seems like a bad idea. anchor="" allows making statements 
about sub resources, and there should be exactly one way to do that (so 
it can be dealt with in a generic parser).

Furthermore, what do you mean by "dynamic scope"?

Option 2) sounds ok, but I'm not sure why it would only be advisory?

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Aug 2009 14:58:34 +0200

Mark Nottingham wrote:
> removing it (i.e., it will be an extension, not called out explicitly in 
> the syntax)?
> ...

I think that not mentioning it will cause both confusion ("where did it 
go and why?") and extra work (it being re-defined for certain relations).

Thus it seems to me that the spec should document it in any case. If 
there's a consensus that it's a bad thing to use, we should add that to 
the documentation, essentially deprecating it.

BR, Julian

---

From: Sam Johnston <[email-masked]>
Date: Thu, 20 Aug 2009 15:06:41 +0200

On Thu, Aug 20, 2009 at 2:58 PM, Julian Reschke <[email-masked]>wrote:

> I think that not mentioning it will cause both confusion ("where did it go
> and why?") and extra work (it being re-defined for certain relations).
>
> there's a consensus that it's a bad thing to use, we should add that to the
> documentation, essentially deprecating it.
>

Given the attribute is rarely used (and when it is it's generally abused -
e.g. rev=canonical) I would suggest that following HTML 5's example and
jumping straight to obsolesence is a better idea than deprecation.

Sam

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Aug 2009 15:13:00 +0200

Sam Johnston wrote:
> ...
> Given the attribute is rarely used (and when it is it's generally abused 
> - e.g. rev=canonical) I would suggest that following HTML 5's example 
> and jumping straight to obsolesence is a better idea than deprecation.
> ...

"deprecating" was the wrong term anyway; as there is no replacement 
(except for defining reverse relations, and using them with "rel").

HMTL5 imho goes too far in not mentioning it at all.

BR, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Thu, 20 Aug 2009 15:20:07 +0200

On Thu, 20 Aug 2009 15:13:00 +0200, Julian Reschke <[email-masked]> wrote:
> Sam Johnston wrote:
>> ...
>> Given the attribute is rarely used (and when it is it's generally  
>> abused - e.g. rev=canonical) I would suggest that following HTML 5's  
>> example and jumping straight to obsolesence is a better idea than  
>> deprecation.
>> ...
>

If we keep it the registry should have the distinction as well as some relations make no sense when reversed, see e.g. canonical above.

However I do not think we should keep it. I'd be fine with an appendix of some sorts explaining why it's gone.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Ian Hickson <[email-masked]>
Date: Thu, 20 Aug 2009 19:06:46 +0000 (UTC)

On Thu, 20 Aug 2009, Julian Reschke wrote:
> "deprecating" was the wrong term anyway; as there is no replacement (except
> for defining reverse relations, and using them with "rel").
> 

HTML5 does define behaviour for rev="", it just makes it non-conforming.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Aug 2009 21:48:16 +0200

> HTML5 does define behaviour for rev="", it just makes it non-conforming.

Sorry, I missed that 
(<http://dev.w3.org/html5/spec/Overview.html#attr-link-rev>).

I think it would be even better if there was a single sentence 
explaining what it means (or used to mean).

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 21 Aug 2009 07:54:37 +1000

My copy of the draft (not yet on mnot.net) currently has:

       <t>The relation type of a link is conveyed in the "rel"  
parameter's value. The "rev" parameter has also
		been used for this purpose historically by some formats, and MAY be  
accommodated as a link-extension, but
		its use is not encouraged nor defined by this specification.</t>

On 21/08/2009, at 5:48 AM, Julian Reschke wrote:

>>>> abused -
> Sorry, I missed that (<http://dev.w3.org/html5/spec/Overview.html#attr-link-rev 
> >).
>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 21 Aug 2009 15:05:29 +1000

On 20/08/2009, at 10:31 PM, Julian Reschke wrote:

>> 1) get rid of it completely; any app that wants to use it can  
>> define it as an extension (as they would for HTML and Atom, which  
>> don't have dynamic scopes).
> WRT 1) that seems like a bad idea. anchor="" allows making  
> statements about sub resources, and there should be exactly one way  
> to do that (so it can be dealt with in a generic parser).
>

I.e., when I put a link in an Atom document, it's context URL is  
static; either feel-level or entry-level.

> Option 2) sounds ok, but I'm not sure why it would only be advisory?

Advisory is perhaps not the right word.

---

From: Ian Hickson <[email-masked]>
Date: Sun, 30 Aug 2009 02:23:31 +0000 (UTC)

On Thu, 20 Aug 2009, Mark Nottingham wrote:
> > would like to request that all relations always be case-insensitive.
> 

All versions of HTML have been case-insensitive throughout their rel="" 
procesing, as far as I can tell.

> > preference if multiple title=, type=, etc, attributes are given.

I assume you mean "acknowledged", not "ew". :-)

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

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.

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

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.

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

So every time someone adds something to the registry, we have to update 
HTML5 to say whether that keyword can be used with HTML?

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

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

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.

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

Does what HTML5 already says on the matter satisfy this?

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

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

> > underdefined. What is the expected UA behaviour when discovering a 
> > link with rel=payment? What are the authoring requirements? What are 
> > the implementation requirements?
> 

So how rel=payment works will differ for Atom and for HTML?

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.

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.

---

From: Sam Johnston <[email-masked]>
Date: Sun, 30 Aug 2009 08:31:12 +0200

> of each attribute is just ignored.

Sounds good.

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

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

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

> XML, or how the XML Style Sheet PI spec defines how <?xml-stylesheet>

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.

> registration mechanism be made significantly simpler than the one

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.

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

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

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

> 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

---

From: Julian Reschke <[email-masked]>
Date: Sun, 30 Aug 2009 12:00:51 +0200

> there UAs that support more?

I think changing the definition of the header (as compared to the 
definition in RFC 2068) based on a single, known-to-be-incomplete 
implementation is a bad idea.

Does Mozilla support the Link header for any relation besides stylesheet 
anyway?

> of each attribute is just ignored.

I'm not convinced that constraining the header syntax based on other 
languages makes a lot of sense; it's a distinct serialization anyway, 
and needs to be treated that way.

What we need for interop are proper test cases, not dumbed down syntax.

> to provide multiple titles per link? How would that work in UI?

The UI would select the language best suited for the user.

> href=""> is just a hyperlink.

It would be great if you could add that explanation to the HTML5 spec 
(last time I checked I didn't understand it).

That being said - this is an interesting proposal; I'm however not sure 
that it's always possible to mandate one or the other.

> HTML5 to say whether that keyword can be used with HTML?

If you are interested in making that decision, yes. It's the same 
situation for other markup languages, and it would be hard to require 
these considerations to be there for every single language relations can 
be used in.

> document? That doesn't sound right at all.

Does it apply? I think that still needs to be defined; potentially while 
revising xml-stylesheet PI spec.

> registration mechanism be made significantly simpler than the one 

    Relation types are registered on the advice of a Designated Expert
    (appointed by the IESG or their delegate), with a Specification
    Required (using terminology from [RFC5226]).

Which part do you think is problematic, and how would you like to see it 
relaxed?

> of the keyword "alternate".

What's wrong with it is that it it's an exception; it's much simpler to 
think of relations as white-space separated strings that are independent 
of each other.

"alternate stylesheet" is legacy HTML needs to continue to support, but 
that doesn't mean that adding more of these exceptions is a good idea.

> number of keywords for all possible depths.

Are there UAs that already support "up up" the way you defined it? How 
did that extension make it into the spec anyway?

Also, you don't need an *infinite* number, just a sufficiently big one.

Best regards, Julian

---

From: Noah Slater <[email-masked]>
Date: Sun, 30 Aug 2009 17:08:29 +0100

> Does Mozilla support the Link header for any relation besides stylesheet

Yes, the following get you feed discovery:

   @rel='alternate' @type='application/atom+xml'

   @rel='alternate' @type='application/rss+xml'

And the Mozilla suite browser natively supports everything from "last", "prev",
"next", "first", "up", "copyright", "about", "search", a bunch of other de-facto
@rel values, and all the ones found here:

  http://www.w3.org/TR/html401/types.html#type-links

Firefox does not support this natively, but there is a plugin to add it.

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

I needed to express the "up" relation in my HTML and Atom documents, and I took
a look at the HTML5 spec to see what the recommendation was. I wasn't planning
on using HTML5, but I figured that it might be a good place to check anyway.

After thinking about it for a while, I decided that there was no sufficient
reason to use more than a single "up" value. My reasoning is that URIs already
provide a mechanism for UAs to determine the spacial position of the current
resource in relation to the one specified via a link element.

Resource URI:

  http://example.org/dir-a/dir-b/doc-b

Links elements:

  <link rel="up" href="/">

  <link rel="up" href="/dir-a/">

  <link rel="up" href="/dir-a/dir-b/">

The hierarchical position of each link can be found by parsing the URI.

Best,

-- 
Noah Slater, http://tumbolia.org/nslater

---

From: Julian Reschke <[email-masked]>
Date: Sun, 30 Aug 2009 18:48:00 +0200

>    @rel='alternate' @type='application/rss+xml'

But that's the link *tag*, not the link header. I just tried, and 
Firefox 3.5 does not appear to check the link header for that.

>   http://www.w3.org/TR/html401/types.html#type-links

But, as far as I can tell, only the link *tag*, not the header.

> Firefox does not support this natively, but there is a plugin to add it.

Same here.

> The hierarchical position of each link can be found by parsing the URI.

Well, that won't always be the case. In the case where the URL hierarchy 
happens to be the actual hierarchy, you really don't need the link 
relation (as demonstrated by the Firefox addon).

BR, Julian

---

From: Noah Slater <[email-masked]>
Date: Sun, 30 Aug 2009 18:42:46 +0100

> Firefox 3.5 does not appear to check the link header for that.

Ah, okay.

I got very excited for a second here because I thought you were saying that
Firefox understands the Link header with rel="stylesheet", but I just tested it
on one of my pages and it doesn't seem to work:

  http://tumbolia.org/quote/zen

I am sending this:

  Link: </style>;rel=stylsheet

Should this work? Am I doing something wrong?

> relation (as demonstrated by the Firefox addon).

It is not as simple as that:

  <link rel="up alternative" type="application/atom+xml" href="/index.atom">

  <link rel="up" hreflang="en" href="/dir-a/index.en">

  <link rel="up" hreflang="de" href="/dir-a/index.de">

In the above cases:

  * You could not infer the "up" relationship from the URI because they have
    character data after the final "/" character, making it otherwise ambiguous
    whether they can be considered direct "parents" of the current resource.

  * You can, however, infer the hierarchical position from the URI after being
    told that they are parents in a document hierarchy.

The only possible time I can think of needing "up up" would be when each parent
link was outside of the URI hierarchy of all the other links. This seems like it
would be such an uncommon thing. Is it worth specifying for?

Best,

---

From: Noah Slater <[email-masked]>
Date: Sun, 30 Aug 2009 18:46:54 +0100

> Does Mozilla support the Link header for any relation besides stylesheet

  Link: </images/big.jpeg>; rel=prefetch

                         - https://developer.mozilla.org/en/Link_prefetching_FAQ

Ah, I wish I could get this to work with rel="stylesheet"!

---

From: Julian Reschke <[email-masked]>
Date: Sun, 30 Aug 2009 19:52:18 +0200

> Should this work? Am I doing something wrong?

It works in some cases; I imagine it wants a mime type as well. See 
<http://www.hixie.ch/tests/adhoc/http/link/>.

>   <link rel="up alternative" type="application/atom+xml" href="/index.atom">

"up alternative"? I hope these are two different link relations?

> would be such an uncommon thing. Is it worth specifying for?

No, I don't think it's worth it.

BR, Julian

---

From: Noah Slater <[email-masked]>
Date: Sun, 30 Aug 2009 18:53:31 +0100

> Should this work? Am I doing something wrong?

Spelling things incorrectly!

After fixing my header, it works perfectly.

Does anyone have any data about how common this is, and how many UAs support it?

I just checked wget:

  wget --page-requisites http://tumbolia.org/quote/zen

This option downloads page requisites, but doesn't download the stylesheet in
this case. At first I considered filing a bug, but considering that the
stylesheet is not directly linked from the HTML, I think it would probably be a
bug to download it from the Link header. Interesting stuff.

Thanks,

---

From: Julian Reschke <[email-masked]>
Date: Sun, 30 Aug 2009 19:56:41 +0200

> Does anyone have any data about how common this is, and how many UAs support it?

I think it's uncommon, as it's only supported by Firefox and Opera. This 
is why I think that designing the spec based on what these 
implementations do right now is a bad idea.

BR, Julian

---

From: Noah Slater <[email-masked]>
Date: Sun, 30 Aug 2009 19:03:32 +0100

> <http://www.hixie.ch/tests/adhoc/http/link/>.

Aha, thanks for the link.

A few weeks ago, some friends did a survey, which concluded:

  'so it only seems that it would be a "problem" if you had a browser which
  *only* requires some stylesheet which isn't CSS. and then the "problem"
  equates to the amount of latency and bandwidth incurred in downloading the
  CSS, which may be less than 1 KB / so link/@type is completely useless'

                                   - http://swhack.com/logs/2009-08-14#T10-21-41

And after correcting my typo, it works, so I wont be adding this.

> "up alternative"? I hope these are two different link relations?

Yes, they I would have used it like:

  <link rel="up" type="application/atom+xml" href="/">

  <link rel="up" hreflang="fr" href="/index.fr">

  <link rel="up alternative" type="application/docbook+xml" href="/index.dbk">

So it would form a simple combination of relationships.

Best,

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 30 Aug 2009 23:30:18 -0700

> From: Ian Hickson [mailto:[email-masked]]
> Sent: Saturday, August 29, 2009 7:24 PM
> 

One bad legacy example doesn't mean we are past this. Following this logic we should never deprecate anything if it is deployed somewhere...

The problem is that it will break clients unaware of this overloading. A client today with support for a set of relation types should not break when another relation type overloads the meaning of a well defined type. The ability to ignore unknown relation types and use the familiar ones is an important capability. Clients must be able to follow the links that make sense to them.

What this combination nonsense is doing is putting well-understood relation types into question when another relation type is present. You simply cannot have it both ways: multiple independent values and combinations.
 
> number of keywords for all possible depths.

This is really not a compelling use case. Are there other use cases?

As for 'up', its definition is too ambiguous to support these combinations. It is currently registered as: "A URI that refers to a parent document in a hierarchy of documents." I can't figure out if 'a parent' can be any parent of a direct parent. If it means a direct parent, your theory of 'automatically works' breaks because UAs will expect the document to be the direct parent, not just a document somewhere 'up' there. If it means any parent, then you can't express a direct parent, but can express a second direct parent.

If you don't want to register multiple 'up-n' relations, consider defining the relation type with an optional extension, such as:

Link: <http://example.com>; rel="up"; level="2"

And it would be better if the 'up' registration entry was more clear indicating it can indicate *any* parent, not just a direct parent. This way, a client always understand what the relation means, but can also support finer details with an extension.

EHL

---

From: Sam Johnston <[email-masked]>
Date: Mon, 31 Aug 2009 08:39:30 +0200

On Mon, Aug 31, 2009 at 8:30 AM, Eran Hammer-Lahav <[email-masked]>wrote:

>
> If you don't want to register multiple 'up-n' relations, consider defining
> the relation type with an optional extension, such as:
>
> And it would be better if the 'up' registration entry was more clear
> indicating it can indicate *any* parent, not just a direct parent. This way,
> a client always understand what the relation means, but can also support
> finer details with an extension.
>

That's an interesting idea - expanding on it:

Link: <http://example.com>; rel="ancestor"; gen[eration]="1"

Generation would be 1 for parents, 2 for grandparents, 3 for
great-grandparents etc.

Another thing I saw before - nobody mandates that ancestry information be
reflected in the URL path segments so the suggestion to "reverse engineer"
ancestors from the URL fails in my mind.

I don't see the harm in pre-populating a "Generic Link Relations" registry
with entries like this so as to give standards writers sensible direction -
otherwise we basically have to make do with whatever weird and wonderful
things people come up with (eg "up up up").

Sam

---

From: Noah Slater <[email-masked]>
Date: Mon, 31 Aug 2009 07:50:40 +0100

On Sun, Aug 30, 2009 at 11:30:18PM -0700, Eran Hammer-Lahav wrote:
> As for 'up', its definition is too ambiguous to support these combinations. It
> is currently registered as: "A URI that refers to a parent document in a
> hierarchy of documents."

This is arguably a good thing.

> I can't figure out if 'a parent' can be any parent of a direct parent. If it
> means a direct parent, your theory of 'automatically works' breaks because UAs
> will expect the document to be the direct parent, not just a document
> somewhere 'up' there. If it means any parent, then you can't express a direct
> parent, but can express a second direct parent.

For what it's worth, my thoughts were that this would represent a resource that
was a direct parent of the resource. And by direct parent, I mean a parent that
must necessarily be passed through if traversing the hierarchy. For the purpose
of this discussion, however, I'm not sure my original intentions matter.

> If you don't want to register multiple 'up-n' relations, consider defining the
> relation type with an optional extension, such as:
>

I'm going to go out on a limb and suggest that most hierarchical relationships
that people will want to express will be such that the level can be inferred
directly from the URI. More over, I fail to understand what kind of UA interface
would need or want this kind of detail.

> indicating it can indicate *any* parent, not just a direct parent. This way, a
> client always understand what the relation means, but can also support finer
> details with an extension.

I worded it to match the existing relations, which I think are suitably vague.

We're talking about reasonably loose document relations, where UAs should be
free to present this information in similarly loose ways. For most cases I can
imagine, simply listing the "up" relations in the order that they appear in the
document source should be enough. But this is up to them.

Best,

---

From: Noah Slater <[email-masked]>
Date: Mon, 31 Aug 2009 07:59:00 +0100

> Link: <http://example.com>; rel="ancestor"; gen[eration]="1"

Not sure if you intentionally changed it to "ancestor" here, but I certainly
wouldn't want to start mint a new relationship name when "up" already has some
modest use in the wild.

> ancestors from the URL fails in my mind.

I wasn't suggesting some new and wonderful technique here.

The "/" character has special meaning within a URI, as do "." and "..", and as
much as we like to tell ourselves that URIs are opaque, folk wisdom tells us
that we can usually treat them like UNIX filenames.

Power users "hack" URIs to navigate, and there are browser extension that
automate it for everyone else. My suggestion to base the depth information on
parsing the URI has some grounding in current practice.

Sure, you could be pedantic, and use UUIDs for all your URIs. And if you did, I
guess you'd have a bit of a problem trying to represent hierarchy depth in your
relations. How common is this though? And moreover, you could use the order of
the relation to indicate depth.

Best,

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 31 Aug 2009 00:09:41 -0700

> From: Noah Slater [mailto:[email-masked]]
> Sent: Sunday, August 30, 2009 11:51 PM
> To: Eran Hammer-Lahav
> Cc: Ian Hickson; HTTP Working Group
> Subject: Re: Last Call: draft-nottingham-http-link-header (Web Linking)
> to Proposed Standard
> 

Ambiguous is not a good thing when it comes to link relations. If the client cannot figure out what the document author intended, things tend to break.
 
EHL

---

From: Sam Johnston <[email-masked]>
Date: Mon, 31 Aug 2009 09:17:31 +0200

> wouldn't want to start mint a new relationship name when "up" already has

Existing use equates "up" with "parent" does it not?

> the relation to indicate depth.

The case I was thinking of was mail archives which tend to be flat (with
messages numbered sequentially), where ancestry relates to threading. Anyway
there will always be an exception - we did consider using UUIDs to identify
resources for OCCI (but abandoned it along with other restrictions, like the
ones you propose, on the URL structure).

Sam

---

From: Julian Reschke <[email-masked]>
Date: Mon, 31 Aug 2009 09:04:40 +0200

> of this discussion, however, I'm not sure my original intentions matter.

Well, you did register the link relation, right?

> would need or want this kind of detail.

CMIS/AtomPub is an example where the hierarchy is not necessarily 
reflected in the URIs, and that's why people want to use the "up" relation.

Now that I realize that "up" does not refer to a specific hierarchy 
level this may need to change, though...

BR, Julian

---

From: Noah Slater <[email-masked]>
Date: Mon, 31 Aug 2009 08:24:58 +0100

On Mon, Aug 31, 2009 at 12:09:41AM -0700, Eran Hammer-Lahav wrote:
> Ambiguous is not a good thing when it comes to link relations. If the client
> cannot figure out what the document author intended, things tend to break.

I think that depends heavily on the application of the technology. The Web is
traditionally a very "loose" environment, where UAs have spent decades figuring
out what authors have meant using reasonably good heuristics. So within that
context, I think that a bit of built in ambiguity promotes flexibility.

Best,

---

From: Noah Slater <[email-masked]>
Date: Mon, 31 Aug 2009 08:25:46 +0100

> ones you propose, on the URL structure).

I prefer to think of my comments as being descriptive, not prescriptive. ;)

Best,

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 31 Aug 2009 00:28:57 -0700

All you have to do to fix this is clearly state that 'up' can be any parent, not just a direct parent. My issue is not with having a generic and flexible relation type, but one that is failing to clearly communicate what it is.

EHL

> Sent: Monday, August 31, 2009 12:25 AM
> To: Eran Hammer-Lahav

---

From: Noah Slater <[email-masked]>
Date: Mon, 31 Aug 2009 08:32:49 +0100

> Well, you did register the link relation, right?

Well sure, but my experience lead me to believe that the situation I describe is
the most common one. I was also aware of the vague nature of the description,
fitting with the other relations, and a bonus for reasons I have described in a
previous email. What I meant is, a post-hoc explanation of my thought process is
hardly normative for the official registration. Hehe.

> reflected in the URIs, and that's why people want to use the "up"

Sure, seems like a reasonable, and not unexpected, use.

> level this may need to change, though...

I'm not sure what this means.

Before I made my application to IANA, I did took the time to look around at what
seemed to be the status-quo. I was definitely swayed by HTML5 having chosen this
relationship name. And despite me not liking the use of "up up up" for depth, I
do not think this contradicts the existing IANA registration.

Best,

---

From: Noah Slater <[email-masked]>
Date: Mon, 31 Aug 2009 08:41:25 +0100

On Mon, Aug 31, 2009 at 12:28:57AM -0700, Eran Hammer-Lahav wrote:
> All you have to do to fix this is clearly state that 'up' can be any parent,
> not just a direct parent. My issue is not with having a generic and flexible
> relation type, but one that is failing to clearly communicate what it is.

I'm actually confused about what you want clarification on.

> parent, but can express a second direct parent.

And the registration says:

  A URI that refers to a parent document in a hierarchy of documents.

I think the "a" in that sentence allows you to choose any.

Best,

---

From: Julian Reschke <[email-masked]>
Date: Mon, 31 Aug 2009 10:14:38 +0200

> I think the "a" in that sentence allows you to choose any.

But that doesn't *necessarily* mean they can be at different distances 
in the hierarchy (there are use cases where a resource is part of 
multiple hierarchies, thus would have multiple "direct" parents).

BR, Julian

---

From: Noah Slater <[email-masked]>
Date: Mon, 31 Aug 2009 09:20:09 +0100

> multiple hierarchies, thus would have multiple "direct" parents).

The registration does not require any cross-relationship between uses of the
relation for a single resource. The parent, depth, and hierarchy of one
relationship could be totally disjoint to another.

Best,

---

From: Julian Reschke <[email-masked]>
Date: Mon, 31 Aug 2009 10:29:40 +0200

> relationship could be totally disjoint to another.

I think I agree with that.

What I wanted to say is that the text in the registry *can* be read to 
support only relations to *direct* parents.

Looking at 
<http://tools.ietf.org/html/draft-divilly-atom-hierarchy-03#section-2.3>, 
I'm pretty sure that that draft restricts "up" to direct parents, so it 
appears we need to invest some work here (maybe head over to the Atom 
mailing list???)

BR, Julian

---

From: Noah Slater <[email-masked]>
Date: Mon, 31 Aug 2009 09:40:14 +0100

> support only relations to *direct* parents.

I feel a bit stupid, but I'm not sure what "direct" means here. Or at least, my
only interpretation of it seems contradictory to the idea that one could
interpret the registration to require it.

Could you provide a few examples?

Thanks,

---

From: Julian Reschke <[email-masked]>
Date: Mon, 31 Aug 2009 10:46:31 +0200

> Could you provide a few examples?

"direct parent" as in "parent", as opposed to "grandparent" or further 
ancestors.

BR, Julian

---

From: Noah Slater <[email-masked]>
Date: Mon, 31 Aug 2009 10:50:59 +0100

Ah, okay.

The only way that would work is if you were considering a document that existed
in multiple hierarchies, and you took the subject of "a" to be any direct parent
within that collection of hierarchies, instead of any parent in any hierarchy.

This an incorrect interpretation of the my registration.

Is it important that we clarify this? For any person that argues for that
interpretation, would it not suffice to argue out that the language is loose
enough that there is no reasonable way to claim one interpretation to the
exclusion of another. Maybe even linking to this email.

What do you think we should do?

Thanks,

---

From: Julian Reschke <[email-masked]>
Date: Mon, 31 Aug 2009 11:58:44 +0200

> This an incorrect interpretation of the my registration.

I agree with that; I just wanted to point out that "a parent document" 
is not necessarily going to convince people that it includes any 
*ancestor*. It appears the use of "up" in CMIS therefore is incorrect 
and needs to be replaced by something else (now including the Atom 
mailing list).

> What do you think we should do?

I think it'll be sufficient to tune the text once "up" gets 
re-registered when the new registry is created. In general this shows 
that it's dangerous to register relations minted by somebody else 
(HTML5) when that spec isn't yet stable.

BR, Julian

---

From: Noah Slater <[email-masked]>
Date: Mon, 31 Aug 2009 11:15:42 +0100

Please keep the me or the W3C in the CSS as I'm not subscribed to the Atom list.

> and needs to be replaced by something else (now including the Atom

I find the wording confusing:

  An Atom link element with a rel attribute value of "up" may be used to
  reference a resource where parent entries of an entry or a feed may be found.

        - http://tools.ietf.org/html/draft-divilly-atom-hierarchy-03#section-2.3

It's not immediately clear to me how this contradicts the IANA registry.

> (HTML5) when that spec isn't yet stable.

Sounds good to me.

Thanks,

---

From: Joe Gregorio <[email-masked]>
Date: Mon, 31 Aug 2009 09:42:21 -0400

> registration mechanism be made significantly simpler than the one

The registration mechanism calls for creating a document, having it
discussed, and then
updating the registry. While that seems like a burden, I'll turn it around
and point
out that it gives current active formats the ability to review the meaning
and request verbiage be added to cover their particular format, such
as the examples you gave above about document level and phrasing level for
HTML5.

Regardless, I don't believe a flat registry with one document per rel type
is going
to be sufficient. There should be a mechanism within the registry to specify
per-media-type
'clarifications' for each rel type. This is particularly important in the
case of new
formats that come along later, like JSON has in the past couple years, that
weren't around when a rel value was registered.

For example, a new media-type Foo comes along in two years, wants to use
the link header and all the registered relations make sense except 'up', how
would
that be noted in the registry?

   Thanks,
   -joe

---

From: Sam Johnston <[email-masked]>
Date: Mon, 31 Aug 2009 16:50:00 +0200

On Mon, Aug 31, 2009 at 3:42 PM, Joe Gregorio <[email-masked]> wrote:

> to be sufficient. There should be a mechanism within the registry to
> specify per-media-type
> the link header and all the registered relations make sense except 'up',
> how would

There's also the option of not listing any standards (except perhaps as
informative references). The registry would give a plain english meaning to
each of the terms and the standards referencing it would describe the
nuances.

Sam

---

From: Sam Johnston <[email-masked]>
Date: Mon, 31 Aug 2009 16:57:49 +0200

> as the examples you gave above about document level and phrasing level for

As another real world example of link relations being [ab]used, VMware's
vCloud API<http://communities.vmware.com/community/developer/forums/vcloudapi>(which
is similar to OCCI) was just released as a tech preview today. It
uses link relations in an XML-based DSL, taking advantage of some that
already exist and adding some of its own.

Sure this is their language and they can do what they like, but these
resources could (and will with OCCI) be rendered as Atom, HTML, etc. so
there's definitely some advantage of roping this kind of innovation in
(read: lowering the barriers to entry).

Mark said it well <http://www.mnot.net/blog/2009/04/14/rev_canonical_bad> a
while back:

Stepping back, I think this sort of thing is going to happen more often, not
> less. Microsoft and Netscape unilaterally extended the Web with MARQUEE and
> BLINK, and it was ugly, but the impact wasn’t nearly as bad as countless Web
> developers all extending the Web in their own way could be. The onus is
> clearly upon organisations like the W3C and IETF to make themselves as
> transparent and approachable to developers as possible, so that the latent
> experience and expertise in them can be drawn upon by these innovators,
> instead of being seen as either irrelevant or impediments.
>

Anyway here's a sample from the tech preview:

*About Links and Link Relations *
>
> The vCloud API makes extensive use of links to describe the context for a resource, list other relevant
>
> resources, and define how they relate to the current resource. These links are the primary way that a server
>
> delivers information to a client about how to access and operate on a resource.
>
>
> XML documents returned in response to client requests typically include one or more links of the form:
>
>
> <Link rel="{relationship}" href="{URL}”
> type="application/vnd.vmware.vcloud.{type}+xml" />
>
> where:
>
> The href attribute value is a URL, which should be considered an opaque identifier (one that the client
>
> should not attempt to parse or interpret) that persists for the life of the referenced entity.
>
>
> The type attribute value defines the content type of the request or response body. This attribute is present
>
> only for links that require a body when used to make a request or return one in a response.
>
>
> The rel attribute value defines the relationship of the current resource to the target resource. This
>
> relationship indicates the HTTP request type to use with the href attribute of the link, as shown in
>
>
> Table1‐1:
> These links provide a way for a resource to inform a client about related resources and the operations that are
>
> permitted on them. For example, a container such as an Org or Catalog can return links to the entities it
>
> contains, or an entity such as a vApp can contain links that enable operations such as power state changes or
>
> virtual device reconfiguration.
>
> Table1-1.  Link Relationships and HTTP Request Types
>
> rel Description HTTP Request
> add: Add an item to the current container. POST
> alternate: A link to an alternate representation of the current resource.
> GET
> copy: Copy the current entity into a container specified
> in the request body. POST
> up: A link to the container of the current resource. GET
> down: An item in the current container resource. GET
> edit: Modify the current entity. POST
> move: Move the current entity into a container
> specified in the request body. POST
> remove: Remove the current resource DELETE
> power:powerOn: Powers on the referenced vApp. POST
> power:powerOff: Powers off the referenced vApp. POST
> power:reset: Resets the referenced vApp. POST
> power:suspend: Suspends the referenced vApp. POST
> power:shutdown: Shuts down the referenced vApp. POST
> upload:default: Uploads file data to a default location POST
> task:cancel: Cancels the referenced task. POST
>

Sam

---

From: Al Brown <[email-masked]>
Date: Mon, 31 Aug 2009 15:49:51 +0000

In CMIS, URIs are opaque and we do not impose any constraints on how URIs
are formed.  Navigation is done through link relations - up and down.
Traditional computer science tends to use parent for a direct ancestor (see
graph/tree models) and ancestor for any node above that specific node in
the hierarchy.  IMO, 'ancestor', 'parent', 'child', and 'descendant'
terminology would be less ambiguous.

The terms 'up' and 'down' tend to provide directional information and it
would be nice if distance could also be conveyed.

I tend to read the up registration as supporting a system that supports a
node belong to more than one hierarchy (graph) and thus having more than
one parent.  I believe the divilly basic navigation draft clarifies up to
direct parent.

-Al

Al Brown
Emerging Standards and Industry Frameworks
CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home
Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home

Office 714 327 3453
Mobile 714 263 6441
Email  [email-masked]
CONFIDENTIAL NOTICE: The contents of this message, including any
attachments, are confidential and are intended solely for the use of the
person or entity to whom the message was addressed. If you are not the
intended recipient of this message, please be advised that any
dissemination, distribution, or use of the contents of this message is
strictly prohibited. If you received this message in error, please notify
the sender. Please also permanently delete all copies of the original
message and any attached documentation.

From:	Julian Reschke <[email-masked]>
To:	Eran Hammer-Lahav <[email-masked]>, Ian Hickson
            <[email-masked]>, HTTP Working Group <[email-masked]>
Cc:	Al Brown/Costa Mesa/IBM@IBMUS
Date:	08/31/2009 12:04 AM
Subject:	Re: Last Call: draft-nottingham-http-link-header (Web Linking)
            to 	Proposed Standard

BR, Julian

---

From: Nicolas Alvarez <[email-masked]>
Date: Mon, 31 Aug 2009 15:46:14 -0300

Noah Slater wrote:
> After thinking about it for a while, I decided that there was no
> sufficient reason to use more than a single "up" value. My reasoning is
> that URIs already provide a mechanism for UAs to determine the spacial
> position of the current resource in relation to the one specified via a
> link element.
> 
> Resource URI:
> 

URIs are opaque, you can't parse them and know what the depth is.

---

From: Nicolas Alvarez <[email-masked]>
Date: Mon, 31 Aug 2009 16:10:48 -0300

Sam Johnston wrote:
> 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?

You don't need to send a giant header with 150 languages. Only send
languages requested by the client via Accept-Language.

---

From: Noah Slater <[email-masked]>
Date: Mon, 31 Aug 2009 20:36:55 +0100

> URIs are opaque, you can't parse them and know what the depth is.

Nonsense, you are free to parse them however you wish.

While RFC 3986 says that "a path segment is considered opaque by the generic
syntax," this does not marry well with folk interpretation. It is certainly not
helped when the immediately preceding paragraph describes "." and ".." as being
"similar to their role within some operating systems' file directory structures
to indicate the current directory and parent directory, respectively."

The de-facto interpretation of the path component is that it is hierarchical
"similar to [it's] role within some operating systems' file directory
structures" and so I stand by my original statements:

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

I'm not saying that URIs are not opaque, because technically they are. I am
arguing that when common practice so overwhelmingly contradicts the conclusions
made from a theoretical perspective, something has gone horribly wrong.

Best,

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Sep 2009 12:38:07 +1000

On 31/08/2009, at 11:42 PM, Joe Gregorio wrote:

> example,
> updating the registry. While that seems like a burden, I'll turn it  
> around and point
> as the examples you gave above about document level and phrasing  
> level for HTML5.

Yes. It's very easy to define something as "whatever I mean, no more,  
no less," but much more useful to define it precisely -- if it's to be  
reused by others. See the current discussion around 'duplicate', for  
example.

> Regardless, I don't believe a flat registry with one document per  
> rel type is going
> 'clarifications' for each rel type. This is particularly important  
> in the case of new

I strongly disagree; the whole point of registered relations is that  
their semantics are independent of format. While there are certainly  
format-specific considerations for each, that can be handled in the  
world of that format (whether it's in a huge, monolithic spec, or  
something more agile).

> the link header and all the registered relations make sense except  
> 'up', how would

It won't; A media type shouldn't say anything about headers. If it  
wants to use links internally, it should either reuse the framework in  
this draft, or (sub-optimally), define its own.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Sep 2009 13:00:46 +1000

The easiest way for them to use the link framework would be to use  
extension relations for ones that are specific to their application...  
i.e., not register them.

Cheers,

On 01/09/2009, at 12:57 AM, Sam Johnston wrote:

> As another real world example of link relations being [ab]used,  
> VMware's vCloud API (which is similar to OCCI) was just released as  
> a tech preview today. It uses link relations in an XML-based DSL,  
> taking advantage of some that already exist and adding some of its  
> own.
>
> Sure this is their language and they can do what they like, but  
> these resources could (and will with OCCI) be rendered as Atom,  
> HTML, etc. so there's definitely some advantage of roping this kind  
> of innovation in (read: lowering the barriers to entry).
>
> Mark said it well a while back:
>
> Stepping back, I think this sort of thing is going to happen more  
> often, not less. Microsoft and Netscape unilaterally extended the  
> Web with MARQUEE and BLINK, and it was ugly, but the impact wasn’t  
> nearly as bad as countless Web developers all extending the Web in  
> their own way could be. The onus is clearly upon organisations like  
> the W3C and IETF to make themselves as transparent and approachable  
> to developers as possible, so that the latent experience and  
> expertise in them can be drawn upon by these innovators, instead of  
> being seen as either irrelevant or impediments.
>
> About Links and Link Relations
>
> <Link rel="{relationship}" href="{URL}” type="application/ 
> vnd.vmware.vcloud.{type}+xml" />
>
> where:
>
> These links provide a way for a resource to inform a client about  
> related resources and the operations that are
> permitted on them. For example, a container such as an Org or  
> Catalog can return links to the entities it
> contains, or an entity such as a vApp can contain links that enable  
> operations such as power state changes or
> alternate: A link to an alternate representation of the current  
> resource. GET
> copy: Copy the current entity into a container specified in the  
> request body. POST
> move: Move the current entity into a container specified in the  
> request body. POST

---

From: Sam Johnston <[email-masked]>
Date: Tue, 1 Sep 2009 06:24:00 +0200

On Tue, Sep 1, 2009 at 5:00 AM, Mark Nottingham <[email-masked]> wrote:

> extension relations for ones that are specific to their application... i.e.,
> not register them.
>

Right, but in that case they should use URLs, right?

Sam

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Sep 2009 16:52:19 +1000

Yes, that's what they are.

On 01/09/2009, at 2:24 PM, Sam Johnston wrote:

> extension relations for ones that are specific to their  
> application... i.e., not register them.
>