Subject: Re: The atom:uri element

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 27 Jun 2005 13:42:26 +0200

On Thu, 26 May 2005 17:13:22 +0200, Eric Scheid  
<[email-masked]> wrote:

>> See http://www.imc.org/atom-syntax/mail-archive/msg13864.html
>
> There are two arguments in parallel here:
>     (1) which is the proper term for a url/uri/iri ?
>     (2) is naming an element after the data type sensible ?
>
> I say the first argument is a red herring, a bike shed, and entirely
> redundant as we've already extensively used "IRI" in the spec.
>
> Consider also:
>     http://www.imc.org/atom-syntax/mail-archive/msg13860.html
>
> We have /author/name and not /author/string for a reason. Why then do we
> have /author/uri?

I guess we won't be nuking the atom:uri element before Atom goes gold?  
I've created a Pace just to have a final stab at it, if it's possible to  
do anything about it:

<http://intertwingly.net/wiki/pie/PaceRenameUriElement>

== Abstract ==

The "atom:uri" element should be renamed or changed.

== Author ==

AsbjornUlsberg

== Status ==

Open.

== Rationale ==

The "atom:uri" element says nothing about its semantics or meaning, just  
about the datatype of its content. As  
[http://www.imc.org/atom-syntax/mail-archive/msg13860.html Danny Ayers  
writes]: "Using atom:uri/atom:iri is only marginally better than saying  
atom:string - it describes how the identifier is put together, it tells  
you nothing about what's being identified.". It is also in conflict with  
the term "IRI" which is the one used in the rest of the specification.

== Proposal ==

Rename the "atom:uri" element or change its type to a Link Construct.

== Impacts ==

Atom parsers which expects "atom:uri" in the documents, although they are  
based on a non-standard nor final version of the Atom document format.

== Notes ==

As this change is mostly editorial and not technical, I think the authors  
are free to find the best suited name for the element.

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

---

From: Dave Pawson <[email-masked]>
Date: Mon, 27 Jun 2005 13:22:34 +0100

> about the datatype of its content.

> Rename the "atom:uri" element or change its type to a Link Construct.

I support the rationale for changing. I'd appreciate even more
some semantics for the element?
  Were you going to add those to the proposal?

-- 
Regards, 

Dave Pawson
XSLT + Docbook FAQ
http://www.dpawson.co.uk

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 27 Jun 2005 15:03:54 +0200

> some semantics for the element?

I agree and have added text to the pace that describes this. I will try to  
add wording for the specification when I find time for it. Not describing  
what we mean with this element might hurt interop and that should be  
avioded.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 27 Jun 2005 07:26:27 -0700

>I guess we won't be nuking the atom:uri element before Atom goes gold?

Correct.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 27 Jun 2005 18:39:39 +0200

> Rename the "atom:uri" element or change its type to a Link

The problem with that proposal, even if it wasn’t too late to
make any changes, is that, well, it replaces atom:uri with a Link
Construct.

A Link Construct has more semantics than the atom:uri element is
supposed to. Firstly, the @rel attribute is unwarranted in this
context, since there is only kind of relation the URI in atom:uri
can have with the entity described by the Name Construct it’s in.
Secondly, the @rel is necessary for Link Constructs because they
are meant to appear in mulitplicity, while atom:uri is not.

You could avoid these problems by removing the restriction to a
maximum of one URI, of course. Then the Link Construct becomes an
obvious choice. But that would require complicating the Name
Construct spec and require significant additionaly complexity in
Atom consumers – for what benefit? I don’t see any tangible gain
in that.

The basic idea to rename the element to something more
descriptive is, of course, not bad. It might have been warranted
to lobby for renaming atom:uri to something other than atom:link,
or maybe for replacing it with a @link attribute on the Name
Construct’s root element.

But, as mentioned, the spec, modulo bugs, is a done deal at this
point.

And if the atom:uri element’s naming really turns out to be the
biggest wart in the spec, then I’ll gladly suffer it. :-)

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

---

From: Dave Pawson <[email-masked]>
Date: Mon, 27 Jun 2005 18:21:09 +0100

On Mon, 2005-06-27 at 18:39 +0200, A. Pagaltzis wrote:
> supposed to.

Whereas the current construct has no semantics to speak of?

> descriptive is, of course, not bad. 

With little, or no, semantics?

> But, as mentioned, the spec, modulo bugs, is a done deal at this

Which, as was pointed out, is not good for interop

Please can we have an informative version of the spec,
with the semantics explained.

Current version, for thicko's|users, like me, is .... 
not good.

-- 
Regards, 

Dave Pawson
XSLT + Docbook FAQ
http://www.dpawson.co.uk

---

From: James Cerra <[email-masked]>
Date: Mon, 27 Jun 2005 12:46:02 -0700 (PDT)

> Current version, for thicko's|users, like me, is .... 

How hard is one little change?  There are two possibilities that I see as easy
to do:

1) Use atom:id instead of atom:uri, and change atom:id intro paragraph so it
'conveys a permanent, universally unique identifier for an entry, feed, person,
or other resource.'

2) Renaming atom:uri to atom:reference and add to the beginning of the
description that it 'conveys an identifier used to reference the person.  It
MAY permanently and uniquely identify the person.'

Just a quick proposal in case anyone thinks there isn't enough time to get
something.  If there isn't enough time to change it (although I think there is
enough time left), that's OK - it will just be a quirk of the spec IMHO.

--
Jimmy Cerra
https://nemo.dev.java.net

____________________________________________________ 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.yahoo.com

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 27 Jun 2005 14:15:14 -0700

At 12:46 PM -0700 6/27/05, James Cerra wrote:
>If there isn't enough time to change it

Again: there isn't. The spec is in front of the IESG for 
consideration, and it has been for many weeks now.

>  (although I think there is
>enough time left)

Could you explain that? Are you proposing that we pull the spec back 
from the IESG, make this change, and then ask them to look again? Or 
something else I'm missing?

--Paul Hoffman, Director

---

From: James Cerra <[email-masked]>
Date: Mon, 27 Jun 2005 18:21:19 -0700 (PDT)

Paul Hoffman, Director,

> consideration, and it has been for many weeks now.

I knew that, but I was unaware of how un-updatable a step that was.  I
apologize for my ignorance.

> something else I'm missing?

No.  I thought that there was room for updates to the draft during IESG
consideration.  That stemmed from unwarranted assumptions on my part, though. 
I feel the proposed changes are too small to worry about recalling it.  On the
other hand, if the spec is sent back by the IESG for other reasons then I
suggest revisiting this issue.

		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search. 
http://info.mail.yahoo.com/mail_250

---

From: Dave Pawson <[email-masked]>
Date: Tue, 28 Jun 2005 18:18:12 +0100

On Mon, 2005-06-27 at 12:46 -0700, James Cerra wrote:
> How hard is one little change?  

I'm not looking for a change. That has been submitted.

I'm looking for an informative, not normative,
version of the spec, which takes time to explain things
instead of being exact, but backed by the 
experience of this list?

Yes, I know the spec is for implementors,
but there are authors out here too,
who need that information.

That I believe is the interop issue.

-- 
Regards, 

Dave Pawson
XSLT + Docbook FAQ
http://www.dpawson.co.uk