Subject: Link housekeeping: PaceFieldingLinks and maintenance

From: Tim Bray <[email-masked]>
Date: Mon, 25 Oct 2004 16:02:14 -0700

I just created PaceFieldingLinks to capture Roy's proposal: 
http://www.intertwingly.net/wiki/pie/PaceFieldingLinks

I also noted that existing link-related Paces are not up-to-date with 
the format-03 draft.  I think I'll ask Sam to consider closing any 
link-related Paces that haven't been updated relative to the current 
format draft when the time comes to discuss them again.  -Tim

---

From: Antone Roundy <[email-masked]>
Date: Mon, 25 Oct 2004 17:31:10 -0600

> http://www.intertwingly.net/wiki/pie/PaceFieldingLinks
Given that people are virtually never going to want the same xml:base 
to apply to @rel and @href, I don't think xml:base should apply to 
@rel.  The idea in the Pace is of course what we want, but xml:base 
doesn't seem like the right way to get there.  Perhaps something like: 
'If the value of "rel" is not an absolute URI, software MUST prepend 
"http://www.iana.org/assignments/TBD/" to it.' or 'If the value of 
"rel" is not an absolute URI, software MUST act as if xml:base were set 
to "http://www.iana.org/assignments/TBD/".'...except we'd need to be 
sure it was clear that that only applied to @rel, and not @href also.

---

From: Danny Ayers <[email-masked]>
Date: Tue, 26 Oct 2004 01:47:15 +0200

Roy's suggestion made sense at the time, but now I seem to be missing something:

"This provides a basis for extensibility of the atom:link element
which provides both the benefits of an IANA registry and those of a
decentralized URI-based mechanism."

In what respect does it provide the benefits of a decentralized
URI-based mechanism, when *every* value has the same base?

It will say it's not like other URIs, but that isn't a problem anyhow.
The nearest problem is telling the difference between two rel values
with the same (local) name.

What's more the potential for reuse of relational terms defined in
other vocabularies is lost.

If we must have registration, why not simply allow registry of full URIs? 

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Robert Sayre <[email-masked]>
Date: Mon, 25 Oct 2004 19:56:52 -0400

> If we must have registration, why not simply allow registry of full URIs? 

I believe the original suggestion[0] was that the attribute value be a 
URI Reference, with Relative References using a base controlled by a 
registry. The proposal didn't touch on registration of full URIs.

Robert Sayre

[0] http://www.imc.org/atom-syntax/mail-archive/msg10681.html

---

From: Mark Baker <[email-masked]>
Date: Mon, 25 Oct 2004 19:55:13 -0400

> URI-based mechanism, when *every* value has the same base?

When the value is a URI, of course.  Silly wabbit!

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

---

From: Tim Bray <[email-masked]>
Date: Mon, 25 Oct 2004 17:08:39 -0700

> URI-based mechanism, when *every* value has the same base?

No, it's a URI reference.  By default the base is the IANA registry.  
You can put a full URI in there or reset the base with xml:base.  -Tim

---

From: Martin Duerst <[email-masked]>
Date: Tue, 26 Oct 2004 13:25:35 +0900

>
 >I also noted that existing link-related Paces are not up-to-date with the 
format-03 draft.  I think I'll ask Sam to consider closing any link-related 
Paces that haven't been updated relative to the current format draft when 
the time comes to discuss them again.  -Tim

Some comments:

- I agree with Antone Rundy that this should always use the IANA registry
   as the base. Making this dependent on xml:base makes this much less
   usable. The Pace should explicitly state that xml:base does not apply.

- In "Link constructs MAY have a rel attribute, whose value MUST
   be a string.", the second part ("whose value MUST be a string")
   is completely superfluous. Any XML attribute value is a string.

- "New assignments must be approved by the IESG.": The most frequent
   way registries that I know are updated is by having an expert reviewer.
   Bothering the IESG with this is way too much of a hurdle.

Regards,    Martin.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 26 Oct 2004 15:36:34 +1000

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

the idea is good, but the pace needs language addressing canonicalisation of
URIs because the URIs which get put into @rel are used for comparison
purposes, not retrieval. The simplest thing that could possibly work would
be language stating that comparison of @rel values is as a character by
character string comparison performed after prefixing the IANA registry
base, and case sensitive/insensitive(?).

e.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 26 Oct 2004 00:48:02 -0700

> base, and case sensitive/insensitive(?).

It doesn't need language on canonicalization.  Just penalize the
losers who don't bother to be consistent.  A plain old case-sensitive
string comparison is sufficient to do the job -- it isn't even necessary
to convert the registered URI reference to absolute form first if the
base URI is set in stone, since people who want to use the full IANA
URI for the registered name should be discouraged from wasting bits.

....Roy

---

From: Danny Ayers <[email-masked]>
Date: Tue, 26 Oct 2004 12:32:35 +0200

> You can put a full URI in there or reset the base with xml:base.  -Tim

Ok thanks, That's the form that made sense, only the wording of the
Pace is a little misleading.

I suggest a rewording of the abstract from:

"Define the rel attribute's value as being a URI reference whose base
is an IANA registry."

to something like:

"Define the rel attribute's value as being a URI reference whose base
is an IANA registry unless otherwise specified."

and the addition of examples, like Eric's text:
[[
rel="foo" and rel="http://example.org/foo" would have different bases. The
former would act as if it is "http://iana.org/assignments/TBD/"+"foo", while
the latter, being an absolute URI, would be what it is.
]]

Historical note - the same kind of defaulting was specified in
PaceLinkRelMechanism...

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 26 Oct 2004 08:06:15 -0700

>   Bothering the IESG with this is way too much of a hurdle.

It is the IESG who assigns expert reviewers and approves their 
actions. We should let the IESG decide how they want to handle this 
without us telling them.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 26 Oct 2004 19:01:32 +0100

> format draft when the time comes to discuss them again.  -Tim

[[[
The value of "rel" MUST be a URI Reference [RFC2396bis, section 
4.1].  For
     the atom:link element, if the xml:base attribute is not 
provided, software
     MUST act as though it were present with a value of
     "http://www.iana.org/assignments/TBD/", which identifies the 
IANA Registry
     of Atom Link Relations.
]]]

Why aren't absolute URIs specified here?

cheers
Bill

---

From: Tim Bray <[email-masked]>
Date: Tue, 26 Oct 2004 11:45:54 -0700

On Oct 26, 2004, at 11:01 AM, Bill de hÓra wrote:

> The value of "rel" MUST be a URI Reference [RFC2396bis, section 4.1].  
> For
>     the atom:link element, if the xml:base attribute is not provided, 
> software
>     "http://www.iana.org/assignments/TBD/", which identifies the IANA 
> Registry
>     of Atom Link Relations.
> ]]]
>

So for things that are registered, like (initially) "alternate" and 
"related", you can just say <link rel="related"> and it all works.  
Unregistered things can be used, but you have to provide the whole URI 
-T

---

From: Martin Duerst <[email-masked]>
Date: Wed, 27 Oct 2004 08:38:07 +0900

Hello Paul,

At 00:06 04/10/27, Paul Hoffman / IMC wrote:
 >It is the IESG who assigns expert reviewers and approves their actions. 
We should let the IESG decide how they want to handle this without us 
telling them.

It turns out that there seem to be two different models of (expert)
reviewers.

The one I refered to is where the RFC defines that there is a reviewer
that has to give his/her okay before things get registered with IANA.
This is the case for charsets (you should know, because you are the
reviewer) and language tags (see http://www.ietf.org/rfc/rfc3066.txt,
Section 3), and media types in general (vnd,...). In these cases,
the IESG doesn't get involved.

The other model, the one you are referring to, is that the IESG
assigns reviewers as part of their decision process. In that case,
it's of course up to the IESG to handle things the way they want.

However, what I was proposing is that we use the model used currently
for charsets, language tags,..., which is considerably more lightweight
and in my view more appropriate for the kind of registration we are
dealing with.

Regards,    Martin.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 26 Oct 2004 20:45:39 -0700

>and in my view more appropriate for the kind of registration we are

In practice, the two models are identical. The IESG person 
responsible for the experts in both cases usually lets the experts do 
what they want with little supervision. Either is fine for what we 
need.

--Paul Hoffman, Director

---

From: Graham Parks <[email-masked]>
Date: Fri, 29 Oct 2004 13:46:37 +0100

Tim Bray wrote:
> format draft when the time comes to discuss them again.

I've updated PaceLinkByLocation.

Graham

---

From: Graham Parks <[email-masked]>
Date: Fri, 29 Oct 2004 13:53:49 +0100

> format draft when the time comes to discuss them again.  -Tim

Can I ask Tim, why do you hate XML namespaces?

Graham

---

From: Graham <[email-masked]>
Date: Sat, 30 Oct 2004 18:47:14 +0100

On 29 Oct 2004, at 7:17 pm, Tim Bray wrote:

> On Oct 29, 2004, at 5:53 AM, Graham Parks wrote:
>
> You could, and I'd answer "I don't, particularly".  So perhaps you 
> should amplify the question.

Because you've spend time creating a Pace that creates something very 
like XML namespaces, but isn't. Either you really hate the XML 
namespace system, or.. I have no idea.

Put another way, why are we trying to shoehorn namespace functionality 
into the rel attribute, instead of seeing if we can add the 
functionality that we want to the pre-existing namespace system?

If we accept PaceLinkByLocation and create an IANA thingy for new link 
types in the atom namespace, we'd have something functionally identical 
to PaceFieldingLinks (URI-based names, default short names, ability to 
extract all link constructs, etc), but be compatible with XMLNS.

Graham

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 30 Oct 2004 14:06:25 -0700

> namespace system, or.. I have no idea.

The latter, most likely.

> functionality that we want to the pre-existing namespace system?

Because rel corresponds better to the preferred behavior if the
recipient does not understand the relationship name.  That is, treat
it as a generic link.

> types in the atom namespace, we'd have something functionally 
> identical to PaceFieldingLinks (URI-based names, default short names, 
> ability to extract all link constructs, etc), but be compatible with 
> XMLNS.

That would be namespace-equivalent to requiring a centrally defined
registry of relationship names, and a bunch of completely unknown
elements in other namespace names.  In order to tie the two together,
Atom would have to use XLink attribute names to indicate that the
other elements are actually links.

Which choice is going to lead to better interoperability for folks
who just want to blog their bits?  XLink or rel?

....Roy

---

From: Graham <[email-masked]>
Date: Sat, 30 Oct 2004 22:34:13 +0100

On 30 Oct 2004, at 10:06 pm, Roy T. Fielding wrote:

>> If we accept PaceLinkByLocation and create an IANA thingy for new 
>> link types in the atom namespace, we'd have something functionally 
> elements in other namespace names.

Which is exactly what Tim is proposing.

>  In order to tie the two together,

If that's your only problem, may I point you to PaceLinkByLocation, 
which solves it*?

Graham

(* And which I mentioned at the very start of the proposal you're 
rebutting, but never mind)

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 30 Oct 2004 15:10:17 -0700

> If that's your only problem, may I point you to PaceLinkByLocation, 

I already did, and it doesn't solve it because namespaced elements
define their own attribute grammars and there is no XML-significant
way of saying "all child elements of this element have attributes
named "href" that define links to the attribute value" other than XLink,
which is why I mentioned it in the first place.

....Roy

---

From: Graham <[email-masked]>
Date: Sat, 30 Oct 2004 23:15:22 +0100

On 30 Oct 2004, at 11:10 pm, Roy T. Fielding wrote:

> define their own attribute grammars

"All child elements of atom:links MUST be Link Constructs"

> there is no XML-significant

"All child elements of atom:links MUST be Link Constructs"

Graham

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 30 Oct 2004 16:05:53 -0700

> "All child elements of atom:links MUST be Link Constructs"

Which is a contradiction of XML namespaces.  Either use them or invent
your own, don't claim to be using them and using properties that they
do not allow.

....Roy

---

From: Graham <[email-masked]>
Date: Sun, 31 Oct 2004 00:36:11 +0100

> your own, don't claim to be using them and using properties that they

Are you seriously trying to argue that the Atom spec is not allowed to 
limit where and which namespaced elements are allowed to appear? I 
think you're very much mistaken.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Sat, 30 Oct 2004 21:37:26 -0700

Graham wrote:

> limit where and which namespaced elements are allowed to appear? I think 
> you're very much mistaken.
> 

I think Roy is pointing out that unprefixed attributes are undefined
in XML Namespaces--"there is no way to construct universal names from
unprefixed attribute names"[0]. In Infoset terms[1], all you have is an
[owner element] and [local name], but no [namespace name], so it's not
actually using xmlns. It's something different:

{[namespace],[local name]} . [owns attr] . [local name] (no ns name)

There is no concept of a "null namespace" or "no namespace" in xmlns, 
that's just shorthand that's not backed up by normative text. In this 
syntax, it's also invalid to write

<foo href="..." xmlns="somuri" />

because "href" is in a namespace.

In my original suggestion[2], the link attributes were in the Atom
namespace. That syntax was actually using xmlns, but it was also a
simplistic reinvention of XLink and/or HLink. The Namespace-based syntax 
also gives rise to the possibility of a profusion of xmlns declarations, 
which is just (my) bad syntax design.

When you get right down to it, we're going to complicate the spec if we 
  define links by containment instead of use a URI reference.

Robert Sayre

[0] http://www.rpbourret.com/xml/NamespaceMyths.htm#myth4
[1] http://www.w3.org/TR/xml-infoset/#infoitem.attribute
[2] http://www.imc.org/atom-syntax/mail-archive/msg10643.html