Subject: Re: Link rel test cases

From: Andreas Sewe <[email-masked]>
Date: Fri, 26 May 2006 15:31:40 +0200

James Holderness wrote:
> For the second I'd recommend this:
> 
>    <link rel="ALTERNATE"
>          href="http://www.snellspace.com/public/alternate2" />
>    <link rel="alternate"
>          href="http://www.snellspace.com/public/alternate" />
>    <link rel="ALTERNATE"
>          href="http://www.snellspace.com/public/alternate2" />
> 
> Also, where does it say that the @rel attribute is case sensitive? I 
> couldn't find anything in RFC4287, but in HTML at least link types are 
> definately case INsensitive [1].

Well, I guess section 4.2.7.2. states this implicitly; names registered 
within the IANA Registry of Link Relation ("alternate") are to be 
interpreted as being equivalent to an IRI 
(<http://www.iana.org/assignments/relation/alternate>). And the path 
component of IRIs is case-sensitive.

But the test cases should IMHO not test whether "ALTERNATE" works, since 
it should not, but whether 
"http://www.iana.org/assignments/relation/alternate" does. But then 
again my reading of 4.2.7.2 might be wrong.

Regards,

Andreas

> [1] http://www.w3.org/TR/html401/types.html#h-6.12

---

From: "James Holderness" <[email-masked]>
Date: Fri, 26 May 2006 13:21:45 +0100

Just following up on these tests. Both are in need of flanking links to 
catch aggregators that just return the first or the last link regardless of 
the @rel. For the first test I'd recommend something like this:

    <link rel="http://example.org/random"
          href="http://www.snellspace.com/public/random" />
    <link rel="http://www.iana.org/assignments/relation/alternate"
          href="http://www.snellspace.com/public/alternate" />
    <link rel="http://example.org/random"
          href="http://www.snellspace.com/public/random" />

    <link rel="ALTERNATE"

As an example, JetBrains Omea currently passes both your tests as they are. 
If they were changed as recommended, it would fail both of them.

Regards
James

James M Snell wrote:
> Yes, I'll make those changes this evening.
>
> James Holderness wrote:
>> May I suggest you add a third link with rel="ALTERNATE" in your second
>> test. As it is you're catching aggregators that choose the first of
>> multiple alternate links, but not catching those that choose the last 
>> link.

---

From: James M Snell <[email-masked]>
Date: Fri, 26 May 2006 08:38:19 -0700

Updated.  Two additional tests were also added.

- James

James Holderness wrote:
> catch aggregators that just return the first or the last link regardless
> of the @rel. For the first test I'd recommend something like this:
> 
> As an example, JetBrains Omea currently passes both your tests as they
> are. If they were changed as recommended, it would fail both of them.
>

---

From: David Powell <[email-masked]>
Date: Fri, 26 May 2006 17:54:08 +0100

> again my reading of 4.2.7.2 might be wrong.

I agree. link@rel is case sensitive as it is an IRI-ref, therefore
ALTERNATE isn't correct. Any resemblance of HTML's link rel is purely
coincidental.

Actually, as @rel is an IRI-ref with
"http://www.iana.org/assignments/relation/" as its base-IRI, sick
stuff like this should work:

<link rel="../relation/alternate" href="http://www.example.com" />

-- 
Dave

---

From: "James Holderness" <[email-masked]>
Date: Fri, 26 May 2006 17:53:28 +0100

I'm still seeing the same old feed. Ran it through the feedvalidator too so 
I don't think it's a cache problem on my side. Is there any reason why it 
shouldn't show up straight away? I'm looking at this URL btw:

http://www.snellspace.com/public/linkreltest.xml

Regards
James

James M Snell wrote:
>> of the @rel.

---

From: "James Holderness" <[email-masked]>
Date: Fri, 26 May 2006 18:05:20 +0100

> <link rel="../relation/alternate" href="http://www.example.com" />

No it shouldn't. It's not actually an IRI-ref. From section 4.2.7.2:

The value of "rel" MUST be a string that is non-empty and matches either the 
"isegment-nz-nc" or the "IRI" production in [RFC3987]. Note that use of a 
relative reference other than a simple name is not allowed.

Regards
James

---

From: "James Holderness" <[email-masked]>
Date: Fri, 26 May 2006 18:35:19 +0100

> component of IRIs is case-sensitive.

I considered that, but if you want to assume IRI comparison semantics, then 
does that mean a link type of "%61lternate" is equivalent to "alternate" 
too? Or what about "HTTP://www.IANA.org:80/assignments/relation/alternate"?

Logically I would assume the simple string comparison in section 5.3.1 of 
RFC3987, but I was hoping this would be documented somewhere more 
explicitly. An atom:id is an IRI too, but it explicitly specifies 
character-by-character, case-sensitive comparisons. By not doing the same 
for link relations the spec kind of leaves things open to interpretation.

> "http://www.iana.org/assignments/relation/alternate" does.

That's what the first test case is supposed to be doing.

Regards
James

---

From: "Robert Sayre" <[email-masked]>
Date: Fri, 26 May 2006 13:57:03 -0400

> for link relations the spec kind of leaves things open to interpretation.

RFC3986, section 6 and RFC3987, section 5 document this procedure very
well. The comparison ladder reduces false negatives in exchange for
processing effort. If you think the ladder is worth climbing in this
case, go for it.

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: James M Snell <[email-masked]>
Date: Fri, 26 May 2006 10:21:27 -0700

David Powell wrote:
>[snip]

From 4.2.7.2 : "Note that use of a relative reference other than a
simple name is not allowed."

so it's either "alternate" or the full URI
"http://www.iana.org/assignments/relation/alternate".  No other form is
allowed.

- James

---

From: James M Snell <[email-masked]>
Date: Fri, 26 May 2006 11:36:23 -0700

Doh! I had updated the wrong test file.

- James

James Holderness wrote:
> 
> I'm still seeing the same old feed. Ran it through the feedvalidator too
> so I don't think it's a cache problem on my side. Is there any reason
> why it shouldn't show up straight away? I'm looking at this URL btw:
>

---

From: David Powell <[email-masked]>
Date: Fri, 26 May 2006 19:54:12 +0100

> processing effort. If you think the ladder is worth climbing in this

Yeah, equally if you are a publisher, and don't want to restrict
interoperability to just the set of clients that climb the ladder,
then don't do anything stupid.

We probably should have specified the "simple string comparison"
method; it is more satisfying to call an implementation that publishes
not obviously equivalent IRIs 'wrong', rather than just 'somewhat unwise'.

-- 
Dave

---

From: "Robert Sayre" <[email-masked]>
Date: Fri, 26 May 2006 15:37:25 -0400

> not obviously equivalent IRIs 'wrong', rather than just 'somewhat unwise'.

Huh, I personally feel that the comparison ladder is better. Sort of
like, "if it comes down to that, we can't help you", even for atom:id.
The WG definitely felt simple string comparison was needed for
atom:id, so we spent *a lot* of time on that text.

I don't feel that effort would pay off here, at all. Especially since
a consumer that matched
"HTTP://www.IANA.org:80/assignments/relation/alternate" would be in
error. That's ridiculous standards weenie stuff, don't you think?

-- 

Robert Sayre

---

From: Martin Duerst <[email-masked]>
Date: Tue, 30 May 2006 12:51:19 +0900

>atom:id, so we spent *a lot* of time on that text.

I think for simple IDs, where there is no expectation of resolution,
character-by-character comparison is better. But either way,
the spec is the way it is now.

>error. That's ridiculous standards weenie stuff, don't you think?

Yes, a content producer that expected
a) HTTP://www.IANA.org:80/assignments/relation/alternate
to always be different from
b) http://www.iana.org/assignments/relation/alternate
would be stupid. But on the other hand, a content producer
that expected a) and b) to always be treated the same would
be ridiculous, too. The conclusion is that a content producer
that uses
HTTP://www.IANA.org:80/assignments/relation/alternate
at all does something wrong.

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: Martin Duerst <[email-masked]>
Date: Tue, 30 May 2006 14:03:42 +0900

At 06:34 06/04/26, James M Snell wrote:
>
>A couple more link rel test cases:
>See the bottom of: http://www.intertwingly.net/wiki/pie/LinkConformanceTests

Just a short comment: the use of unregistered,
(see http://www.iana.org/assignments/urn-namespaces)
made-up urn namespaces such as linkreltest in
<id>urn:linkreltest:feed</id>
doesn't really match well with the fact that
atom is an IETF format, and tests are supposed
to be correct and conforming by themselves.

Regards,   Martin.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 30 May 2006 15:50:09 +0200

* Martin Duerst <[email-masked]> [2006-05-30 08:00]:
> The conclusion is that a content producer that uses
> HTTP://www.IANA.org:80/assignments/relation/alternate at all
> does something wrong.

+1

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: James M Snell <[email-masked]>
Date: Tue, 30 May 2006 09:03:45 -0700

Fixed! Changed to use tag:

---

From: "James Holderness" <[email-masked]>
Date: Wed, 31 May 2006 01:01:28 +0100

Unfortunately it looks like you managed to break the XML while doing this. 
The id tag in the second entry is not closed properly.

Regards
James

---

From: James M Snell <[email-masked]>
Date: Tue, 30 May 2006 17:18:30 -0700

Doh! Dangnabbit. Fixed. For real this time.

James Holderness wrote:
> 
> Unfortunately it looks like you managed to break the XML while doing
> this. The id tag in the second entry is not closed properly.
> 
> Regards
> James
> 
> James M Snell wrote:

---

From: "James Holderness" <[email-masked]>
Date: Wed, 31 May 2006 01:25:09 +0100

Martin Duerst wrote:
> be ridiculous, too.

I agree completely, but as a content consumer I still need to know whether 
to use IRI::Compare or String::Compare when I do encounter some ridiculous 
feed that uses example (a). I'm hoping for a simple answer along the lines 
of "Use IRI:Compare", "Use String::Compare", or "The spec doesn't say, so 
you may use whatever you prefer".

Also, I would think the authors of the feedvalidator would probably want to 
know whether a feed that used example (a) should be considered invalid as 
well as ridiculous. In other words, does it deserve an error, or merely a 
warning?

Regards
James

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 30 May 2006 20:42:16 -0400

> you may use whatever you prefer".

The URI/IRI specs say "use whatever you prefer". If you don't like
that, have James add it to his revision of 4287. :)

-- 

Robert Sayre

---

From: "James Holderness" <[email-masked]>
Date: Wed, 31 May 2006 02:02:09 +0100

> that, have James add it to his revision of 4287. :)

Thanks. That's not how I read RFC3987, but I'm happy to accept your 
interpretation.

Regards
James

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 30 May 2006 21:49:24 -0400

I think James forgot to cc the list

---------- Forwarded message ----------
From: James M Snell <[email-masked]>
Date: May 30, 2006 9:38 PM
Subject: Re: Link rel test cases
To: Robert Sayre <[email-masked]>

Robert Sayre wrote:
> [snip]...have James add it to his revision of 4287. :)
>
>

Pardon, what the hell are you talking about?  Do you really, honestly
believe that being a complete ass is a productive use of anyone's time?

- James

-- 

Robert Sayre

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 30 May 2006 22:25:27 -0400

Hmm, do you harass everyone who disagrees with you like this? I am
kind of taken aback by this unprofessional conduct. I don't see how I
am supposed to participate in an IETF working group if the document
authors are going to engage in this kind of vitriol. I wonder if you
think it's ok to write this kind of thing in private email. I'm
disappointed. :/

On 5/30/06, James M Snell <[email-masked]> wrote:
> [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST]
>
> Had I meant to cc the list, it stands to reason that I would have cc'd
> the list.
>
> I've grown quite tired of this
> Insult-James-And-Everything-He-Does-And-Says campaign of yours.  You are
> accomplishing nothing. Get a life and move on.
>
> - James
>
> [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST]
>
> Robert Sayre wrote:
> >

-- 

Robert Sayre

---

From: Martin Duerst <[email-masked]>
Date: Wed, 31 May 2006 14:15:39 +0900

At 10:02 06/05/31, James Holderness wrote:
>Thanks. That's not how I read RFC3987, but I'm happy to accept your interpretation.

Well, RFC 3987 (and 3986) don't *exactly* say "use whatever you prefer",
but for the case at hand, what they say comes pretty close.
What they try to do is give advice on what kind of normalization
or comparison function(s) is/are adequate in which case.
Given that it's difficult to immagine every possible case in
advace, the advice they give unfortuanetly has to be somewhat
vague.

BTW, as a co-author of RFC 3987, I of course appreciate any
suggestion on how to make it clearer, and any suggestions for
fixes or changes (should they be necessary). These should be
directed to [email-masked].

Regards,     Martin.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 31 May 2006 14:41:16 +0200

* James Holderness <[email-masked]> [2006-05-31 02:40]:
> I agree completely, but as a content consumer I still need to
> know whether to use IRI::Compare or String::Compare when I do
> encounter some ridiculous feed that uses example (a). I'm
> hoping for a simple answer along the lines of "Use
> IRI:Compare", "Use String::Compare", or "The spec doesn't say,
> so you may use whatever you prefer".

RFC4287 defines the relation value in terms of IRIs, but does not
require that relations be compared as such, and then constrains
the set of values to a subset of IRIs. This constrained set is
more amenable to simple string comparison. My interpretation of
these facts is that string comparison is explicitly expected.

Given then that all implementations that I have read the source
of do indeed compare relation values as strings, my conclusion is
that while you are free to compare them as IRIs, doing so is
unwise; likewise, while you are free to specify registered
relation values in your published feeds as absolute IRIs
including the http://www.iana.org/assignments/relation/ base,
doing so is unwise.

The spec indeed doesn’t say, so you may indeed use whatever you
prefer. That does not mean all preferences are equally wise.

Regards,

---

From: Ernest Prabhakar <[email-masked]>
Date: Wed, 31 May 2006 07:55:42 -0700

Hi Robert,

While I'm not entirely thrilled with James, and I believe you provide  
some useful perspective,
if you think it is appropriate and ethical to respond by posting  
private email to the list, I must reluctantly conclude that this list  
is better off without you.

Sincerely,
Ernest Prabhakar

---

From: James M Snell <[email-masked]>
Date: Wed, 31 May 2006 08:23:34 -0700

> these facts is that string comparison is explicitly expected.

+1. I don't believe any reasonable implementation should be expected to
do anything more than a simple case-sensitive string comparison of the
IRI.  If an implementation chooses to be forgiving and perform some form
of normalized comparison, then that's the implementations choice.  In
Abdera, I went ahead and checked in a change that normalizes the IRI
then compares the result with the
"http://www.iana.org/assignments/relation/alternate" form.

> including the http://www.iana.org/assignments/relation/ base,

I wouldn't say comparing as IRI's in unwise as much as it is simply very
forgiving.  Publishing a feed that uses rel values that are not in a
normalized form is unwise as your pretty much guaranteeing that folks
won't be able to process your feed properly.

- James

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 31 May 2006 11:44:33 -0400

> is better off without you.

James has taken private conversations on-list:

[  ] yes
[  ] no

So please, spare me the lecture. I don't want to get nasty emails from
James anymore. My problem is solved.

-- 

Robert Sayre

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 31 May 2006 18:54:05 +0200

* Robert Sayre <[email-masked]> [2006-05-31 17:55]:
> So please, spare me the lecture. I don't want to get nasty
> emails from James anymore. My problem is solved.

If you hadn’t dropped an asinine jab at him into a completely
unrelated thread you might not have created the problem that you
would then need to “solve” in the first place.

Regards,

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 31 May 2006 13:23:39 -0400

On 5/31/06, A. Pagaltzis <[email-masked]> wrote:
> My interpretation of

Incorrect.

-- 

Robert Sayre

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 31 May 2006 13:34:27 -0400

On 5/31/06, A. Pagaltzis <[email-masked]> wrote:
>
> If you hadn't dropped an asinine jab at him into a completely
> would then need to "solve" in the first place.

Actually, those were just the latest two. But you didn't know that,
did you? How about you go back to writing your Atom code?

If you have further comments, send them somewhere else. If you send
them to me, I'll be sure to put them with the other unread emails from
you.

-- 

Robert Sayre

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 31 May 2006 19:57:07 +0200

Hi Robert,

* Robert Sayre <[email-masked]> [2006-05-31 19:35]:
> >My interpretation of these facts is that string comparison is
> >explicitly expected.
> 
> Incorrect.

I don’t see how, although I can see how what I wrote might be
ambiguous. Substitute “expected” by “anticipated and provided
for” to get something closer to what I meant, perhaps.

Regards,

---

From: Tim Bray <[email-masked]>
Date: Wed, 31 May 2006 11:04:33 -0700

On May 30, 2006, at 5:25 PM, James Holderness wrote:

> I agree completely, but as a content consumer I still need to know  
> whether to use IRI::Compare or String::Compare when I do encounter  
> some ridiculous feed that uses example (a). I'm hoping for a simple  
> answer along the lines of "Use IRI:Compare", "Use String::Compare",  
> or "The spec doesn't say, so you may use whatever you prefer".

Both are perfectly legal.  IRI::Compare will avoid some false  
negatives at the cost of burning some CPU cycles.  Postel's law would  
suggest using IRI::Compare initially, but if a profiler revealed it  
to be a performance bottleneck, I'd nuke it in favor of strcmp()  
without a second's hesitation.  I actually wouldn't be surprised if  
that happened; case-insensitivity and Unicode sit poorly together and  
are a notorious source of performance sinkholes. -Tim

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 31 May 2006 14:14:37 -0400

On 5/31/06, A. Pagaltzis <[email-masked]> wrote:
> I don't see how

If it was explicit, you wouldn't need to interpret. Thanks for playing.

-- 

Robert Sayre

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 31 May 2006 20:14:12 +0200

* Robert Sayre <[email-masked]> [2006-05-31 19:55]:
> >unrelated thread you might not have created the problem that
> >you would then need to "solve" in the first place.
> 
> Actually, those were just the latest two. But you didn't know
> that, did you?

No, I didn’t. You sure picked an unfortunate sample to forward
back to the list, though.

> How about you go back to writing your Atom code?

How about you leave conjecture out of your commentary about other
people’s activities?

> If you have further comments, send them somewhere else. If you
> send them to me, I'll be sure to put them with the other unread
> emails from you.

Duly noted. I only ever remember sending you a single email
anyway, and that was a thank-you note for one really good
criticism you posted here somewhat recently that even refrained
from any personal attacks. What a pity that it would go unread.

Regards,

---

From: James M Snell <[email-masked]>
Date: Wed, 31 May 2006 11:20:14 -0700

+1

Tim Bray wrote:
>> answer along the lines of "Use IRI:Compare", "Use String::Compare", or
>> "The spec doesn't say, so you may use whatever you prefer".
> 
> Both are perfectly legal.  IRI::Compare will avoid some false negatives
> at the cost of burning some CPU cycles.  Postel's law would suggest
> using IRI::Compare initially, but if a profiler revealed it to be a
> performance bottleneck, I'd nuke it in favor of strcmp() without a
> second's hesitation.  I actually wouldn't be surprised if that happened;
> case-insensitivity and Unicode sit poorly together and are a notorious
> source of performance sinkholes. -Tim
> 
>

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 31 May 2006 20:37:06 +0200

* Robert Sayre <[email-masked]> [2006-05-31 20:25]:
> >> >My interpretation of these facts is that string comparison
> >> >is explicitly expected.
> 
> If it was explicit, you wouldn't need to interpret.

Okay, more imprecise wording. Make that “specifically
anticipated.”

Regards,

---

From: James M Snell <[email-masked]>
Date: Wed, 31 May 2006 12:09:56 -0700

For me, the difference tends to fall in terms of whether or not the IRI
is intended to be dereferenceable or not.  If the IRI is intended to be
used solely as an indentifier (e.g. atom:id, XML Namespaces, etc), then
character-comparison (at a maximum) is appropriate.  If the IRI is
intended to be a navigatable reference, then some degree of
normalization is appropriate.

In the case of the link/@rel and category/@scheme, Atom does not say
whether or not the IRI's should be considered to be dereferenceable.
@rel and @scheme are clearly intended to be used primarily as identifiers.

- James