Subject: Revised PaceFieldingLinks

From: Tim Bray <[email-masked]>
Date: Tue, 09 Nov 2004 12:35:33 -0800

Removed superfluous "MUST be a string" language per Martin Dürst.

Dropped the use of xml:base to force the base URI for rel= per 
suggestion from Roundy, Dürst, et al.

Revised the abstract per Ayers.

  http://www.intertwingly.net/wiki/pie/PaceFieldingLinks

  -Tim

---

From: Antone Roundy <[email-masked]>
Date: Tue, 9 Nov 2004 13:54:16 -0700

>  http://www.intertwingly.net/wiki/pie/PaceFieldingLinks
If we can accept the Pace and then argue whether to add more values to 
the initial list, then this looks like a good step forward.  As 
difficult as the link discussion has been, any step forward may be 
worth taking, even if it's small.

One addition that might be helpful in avoiding misunderstandings: After 
"the base URI...", clarify with an additional sentence along the lines 
of "Unregistered values MUST be Absolute URIs, and MUST NOT point to 
any location beneath 'http://www.iana.org/assignments/TBD/'."  Obvious? 
  Perhaps.  But a careless or uninformed reading (someone who doesn't 
realize that the base URI is only applied to non-absolute URIs) could 
miss the fact that one can use unregistered values.

---

From: Graham <[email-masked]>
Date: Tue, 9 Nov 2004 22:32:40 +0000

Proposals for a new XML namespace mechanism should be directed to an 
XML WG, surely?

If we must put up with this nonsense, I need to ask, is 
rel="http://www.iana.org/assignments/TBD/related" a valid value? What 
about "../TBD/related"? I don't see the benefit of mapping them onto a 
default namespace, so if those 2 are valid then doing a mapping the 
relative URI onto a base and doing URI comparison is a waste of cycles. 
Why not do what we do with content type and have the values be names on 
their own? And why are we using capital letters for idiots for that and 
not for this? Please reconcile the two.

Graham

---

From: Danny Ayers <[email-masked]>
Date: Wed, 10 Nov 2004 00:15:49 +0100

Looks plenty good enough for the editors.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 10 Nov 2004 00:54:02 +0100

>  http://www.intertwingly.net/wiki/pie/PaceFieldingLinks

This base URI stuff makes no sense to me and I am opposed to
requirements such as

  Link constructs MAY have a type attribute, whose
  value MUST be a registered media type [RFC2045].

As that would require implementations to be updated every other
day in order to tell whether the document is (not) conforming.

---

From: Robert Sayre <[email-masked]>
Date: Tue, 09 Nov 2004 19:49:54 -0500

Graham wrote:

> Proposals for a new XML namespace mechanism should be directed to an XML 
> WG, surely?

You seem to think XML Namespaces have properties they don't possess. 
Besides, we're talking about attribute values.

> about "../TBD/related"?

I would use your friendly neighborhood library, examples below.

> I don't see the benefit of mapping them onto a 

I don't see why you would make a big stink about this. Pretty much 
everyone else has said this is a reasonable compromise, and the code for 
Shrook would be totally trivial.

---------------------------------
#import <Foundation/Foundation.h>

int main (int argc, const char * argv[]) {
     NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

     NSURL * baseURL = [NSURL
                  URLWithString:@"http://www.iana.org/assignments/TBD/"];

     NSLog([[NSURL
             URLWithString:@"alternate"
             relativeToURL:baseURL] absoluteString]);

     NSLog([[NSURL
             URLWithString:@"http://www.iana.org/assignments/TBD/related"
             relativeToURL:baseURL] absoluteString]);

     NSLog([[NSURL
             URLWithString:@"../TBD/alternate"
             relativeToURL:baseURL] absoluteString]);

     NSLog([[NSURL
             URLWithString:@"http://franklinmint.fm/foo"
             relativeToURL:baseURL] absoluteString]);

     NSLog([[NSURL
             URLWithString:@"../../assignments/TBD/alternate"
             relativeToURL:baseURL] absoluteString]);

     NSLog([[NSURL
             URLWithString:@"vemmi://franklinmint.fm/foo"
             relativeToURL:baseURL] absoluteString]);

     NSLog([[NSURL
             URLWithString:@".././.././assignments/TBD/alternate"
             relativeToURL:baseURL] absoluteString]);

     [pool release];
     return 0;
}

---------------------------------
Output:

[Session started at 2004-11-09 19:35:40 -0500.]
... 19:35:41.050 ... http://www.iana.org/assignments/TBD/alternate
... 19:35:41.051 ... http://www.iana.org/assignments/TBD/related
... 19:35:41.051 ... http://www.iana.org/assignments/TBD/alternate
... 19:35:41.052 ... http://franklinmint.fm/foo
... 19:35:41.052 ... http://www.iana.org/assignments/TBD/alternate
... 19:35:41.052 ... vemmi://franklinmint.fm/foo
... 19:35:41.052 ... http://www.iana.org/assignments/TBD/alternate

Executable “PaceFieldingLinks” has exited with status 0.

----------------------------------

If there's a bottleneck here, it's probably NSLog().

Robert Sayre

---

From: Graham <[email-masked]>
Date: Wed, 10 Nov 2004 01:09:57 +0000

On 10 Nov 2004, at 12:49 am, Robert Sayre wrote:

> everyone else has said this is a reasonable compromise, and the code 
> for Shrook would be totally trivial.

Yes, it's reasonable. That still doesn't mean I think it makes sense. 
There's very little XML you can come with that wouldn't be trivial for 
me to implement. That doesn't make it a good idea. One of the goals of 
Atom is that it be cleanly specified, which to me makes internal 
consistency between elements a worhty goal.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Tue, 09 Nov 2004 20:18:51 -0500

> consistency between elements a worhty goal.

The @rel of <link> must be consistent with the @type of <content>? 
Sounds like a false goal. You can call the same built-in library 
function for every @rel you will ever encounter. Seems clean to me. For 
the problem with <content>, blame MIME.

Robert Sayre

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 9 Nov 2004 17:45:05 -0800

>  http://www.intertwingly.net/wiki/pie/PaceFieldingLinks

I think it would be better if my name wasn't in the page title.
I could come up with a dozen or so different ways of providing
extensible links in XML -- this one was just the simplest way
of making an attribute value extensible.  I would not call any
of them the "Fielding" way.

It would be simpler to modify the proposal to just say that
the attribute is either a URI or a token, where the token is
equivalent to the URI obtained from appending the token to
"http://www.iana.org/assignments/relations/".  In fact, I'll do
that right now.

Another alternative would be to remove the generic link construct
and simply use namespaces for all of the metadata.  Either XLink
or RDF could be used to indicate when an attribute value is a URI
reference (and thus a link).  Note, however, that neither RDF nor
XLink are simple, nor are they proven solutions for extensibility
by any reasonable measure -- they are simply a means of associating
crosscutting behavior (similar to aspect-oriented programming) as
an attempt to recover a centralized meaning from namespaces'
decentralized collision avoidance strategy.

None of that discussion will help the WG reach rough consensus,
however.  There are even valid arguments for not allowing any
sort of extensibility beyond that of ignore-unknown-elements.

Tim, you might want to consider taking all of the link and metadata
proposals and organizing them as a ladder, with levels of extensibility
being the rungs.  Then get each person to indicate how far up they
are willing to climb.  I'd do that myself, but I still haven't figured
out why I subscribed to the list in the first place, aside from the
pure entertainment value of watching a group of professional and
semi-professional writers try to reach consensus on a design, and
might disappear if I come to my senses.

....Roy

---

From: Tim Bray <[email-masked]>
Date: Tue, 09 Nov 2004 19:17:45 -0800

> I think it would be better if my name wasn't in the page title.

It won't go into the spec, our lengthy PaceWhatchamacallit tags are the 
equivalent of what W3C Working Groups call "Issue H27" and so on.  Your 
name will not impinge on public consciousness past our Last Call.  
Until, of course, someone complains about the lameness of Atom's 
linking primitives, when of course we will blame it all on you.

> "http://www.iana.org/assignments/relations/".  In fact, I'll do

That's fine, except for the language about "interpreting the link the 
same way as it interprets generic metadata" adds no value, so, since 
we're whacking away at the Wiki, I'll replace that with a note that 
values of "rel=" impose no obligations on software behavior.

>   There are even valid arguments for not allowing any

Indeed, except for we keep hearing assertions that in this particular 
area of linking elements, extensibility is golden.  Plus, the cost is 
low.

> being the rungs.  Then get each person to indicate

I think you joined us late enough to have forgone the benefits of a 
couple of thousand messages on link extensibility, plus assorted 
surveys and polls.  I think the WG understands each other on this now, 
and speaking as co-chair, I think that PaceFieldingLinks is pretty well 
as far as the WG is prepared to go.

>  the
> semi-professional writers try to reach consensus on a design

I think that form of entertainment is widely available across the IETF 
landscape. -Tim

---

From: Antone Roundy <[email-masked]>
Date: Tue, 9 Nov 2004 20:37:48 -0700

'The value of "rel" MUST be either a name, which is non-empty and does 
not contain any colon (":") characters, or a URI [RFC2396bis, section 
3].'

Are we going to allow relative URIs?  Or shall we change that to:

'The value of "rel" MUST be either a name, which is non-empty and does 
not contain any colon (":") characters, or an absolute URI [RFC2396bis, 
section 4.3].'

I can't think of any reason to allow relative URIs...nor any reason why 
anyone would attempt to use one...so maybe it doesn't matter that much. 
  But unless there would be some value in allowing relative URIs, we may 
as well nail this down more tightly.

---

From: Tim Bray <[email-masked]>
Date: Tue, 09 Nov 2004 20:12:13 -0800

On Nov 9, 2004, at 7:37 PM, Antone Roundy wrote:

> not contain any colon (":") characters, or an absolute URI 
> [RFC2396bis, section 4.3].'

Er, Ray is using the terminology carefully, and saying URI not URI 
reference, but it would be better to underline this and say "No 
relative URIs." -Tim

---

From: Eric Scheid <[email-masked]>
Date: Wed, 10 Nov 2004 15:22:52 +1100

> as well nail this down more tightly.

I can think of reasons to disallow relative URIs, all to do with the
intended use of the URI as tokens needing exact-matching-comparisons, not
addresses for retrieval.

+1 to "absolute URI"

e.

---

From: Graham <[email-masked]>
Date: Wed, 10 Nov 2004 04:37:27 +0000

On 10 Nov 2004, at 4:12 am, Tim Bray wrote:

>> 'The value of "rel" MUST be either a name, which is non-empty and  
>> does not contain any colon (":") characters, or a URI [RFC2396bis,  
>> section 3].'
>>
>> 'The value of "rel" MUST be either a name, which is non-empty and  
>> does not contain any colon (":") characters, or an absolute URI  

Erm, I thought when a name was used it was really a relative URI to the  
IANA base? Meaning that the value of rel is always a URI reference and  
never just a name? Thus resolving that reference  
("related","./related","http://iana.etc/related","http://example.com/ 
extension",etc), would always give you the absolute URI of the  
relation. That's exactly what the processing model described does. Why  
not say so?

Graham

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 10 Nov 2004 00:20:54 -0800

>> Er, Roy is using the terminology carefully, and saying URI not URI  

I was indeed being precise and referring to an actual syntax production
that does not include relative references but does include fragments
(for the truly pedantic).  We can't say "No relative URIs" because
some people can't handle the combination of those two words without
a conniption fit, and we can't say "Only absolute URIs" because that
would exclude fragment identifiers.  At best we could add "Note that
relative references to a URI are not allowed."

On Nov 9, 2004, at 8:37 PM, Graham wrote:
> Erm, I thought when a name was used it was really a relative URI to  
> the IANA base? Meaning that the value of rel is always a URI reference  
> and never just a name? Thus resolving that reference  

Because that is what the proposal formerly said, before it was  
simplified
by removing that feature.  There are no relative references of interest
here other than the flat namespace of the registry itself, so there is
no real value in treating it as a special case of URI reference.  We get
the same effect by just concatenating the two, as Antone suggested
in a prior thread.

The value this has over XML namespaces is twofold:

   1) it encourages standardization on a small set of commonly
      agreed terms by placing those terms in a community location
      and giving them efficiency-preference in the data format; and

   2) the relation is defined as a form of content, rather than
      as a byproduct of XML name collision avoidance.

I think the IANA registry should be as simple as possible -- like
the recent changes to the header field registry and various proposals
for a URI scheme registry.  There is no need for IESG approval.

....Roy

---

From: Graham <[email-masked]>
Date: Wed, 10 Nov 2004 12:34:31 +0000

On 10 Nov 2004, at 8:20 am, Roy T. Fielding wrote:

> by removing that feature.

How is it a simplification? Let's code it (in Cocoa):

Either:
NSURL *baseURL=[NSURL 
URLWithString:@"http://www.iana.org/assignments/relation/"];
NSURL *relationURL=[NSURL URLWithString:rel baseURL:baseURL];

vs

NSURL *relationURL;
if ([rel rangeOfString:@":"].location==NSNotFound) {
	relURL=[NSURL 
URLWithString:[@"http://www.iana.org/assignments/relation/" 
stringByAppendingString:rel]];
} else {
	relURL=[NSURL URLWithString:rel];
}

> There are no relative references of interest
> no real value in treating it as a special case of URI reference.

OK, I get that there aren't any valid relative URI refs that aren't 
part of the registry, so I get your motivation for the change. It 
doesn't actually lead to a simplification of the spec or the code in 
any language that has URL classes.

Graham

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 10 Nov 2004 14:09:31 -0800

> How is it a simplification? Let's code it (in Cocoa):

Do you seriously expect me to evaluate simplicity based on whether
or not a system library function already exists in Cocoa?

> 	relURL=[NSURL URLWithString:rel];

Or you could just use the first one for both. Given that the base URI
is slash-terminated, the result will be the same.  Alternatively,
I could just ask the Cocoa developers to add a catURI(base, rel)
function if LOC is an issue.

> any language that has URL classes.

It does in any code that is smart enough to just treat them as strings.
Just because you have URL classes doesn't mean you have to use them.

....Roy

---

From: Graham <[email-masked]>
Date: Thu, 11 Nov 2004 01:18:23 +0000

> or not a system library function already exists in Cocoa?

My point is that before the simplifcation, it was possible to get to 
the final relation-URI with a single function call that surely exists 
in every URI-aware system library. Very elegant.

> Or you could just use the first one for both.

No you can't. The proposal allows for relation names to be registered 
that include dots and slashes. If one of those were treated as relative 
URI it would come up with a different result to appending.

> Just because you have URL classes doesn't mean you have to use them.

Since the proposal doesn't say what comparison method should be used (a 
big omission btw), deferring to the URI class and it's isEqual: method 
seems the only prudent thing to do.

Graham