Re: The atom:uri element
On Tue, 28 Jun 2005 03:21:19 +0200, James Cerra [EMAIL PROTECTED] wrote: I knew that, but I was unaware of how un-updatable a step that was. I apologize for my ignorance. The same goes for me. No. I thought that there was room for updates to the draft during IESG consideration. That stemmed from unwarranted assumptions on my part, though. Same here. On the other hand, if the spec is sent back by the IESG for other reasons then I suggest revisiting this issue. That sounds like a good idea. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: The atom:uri element
On Mon, 2005-06-27 at 12:46 -0700, James Cerra wrote: 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. 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
Re: The atom:uri element
On Thu, 26 May 2005 17:13:22 +0200, Eric Scheid [EMAIL PROTECTED] 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»
Re: The atom:uri element
On Mon, 2005-06-27 at 13:42 +0200, Asbjørn Ulsberg wrote: The atom:uri element should be renamed or changed. == Rationale == The atom:uri element says nothing about its semantics or meaning, just about the datatype of its content. == Proposal == 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
Re: The atom:uri element
On Mon, 27 Jun 2005 14:22:34 +0200, Dave Pawson [EMAIL PROTECTED] wrote: I support the rationale for changing. I'd appreciate even more 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. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: The atom:uri element
At 1:42 PM +0200 6/27/05, Asbjørn Ulsberg wrote: I guess we won't be nuking the atom:uri element before Atom goes gold? Correct. --Paul Hoffman, Director --Internet Mail Consortium
Re: The atom:uri element
* Asbjørn Ulsberg [EMAIL PROTECTED] [2005-06-27 13:50]: Rename the atom:uri element or change its type to a Link Construct. 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/
Re: The atom:uri element
On Mon, 2005-06-27 at 18:39 +0200, A. Pagaltzis wrote: * Asbjørn Ulsberg [EMAIL PROTECTED] [2005-06-27 13:50]: Rename the atom:uri element or change its type to a Link Construct. 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. Whereas the current construct has no semantics to speak of? The basic idea to rename the element to something more descriptive is, of course, not bad. With little, or no, semantics? But, as mentioned, the spec, modulo bugs, is a done deal at this point. 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
Re: The atom:uri element
Rename the atom:uri element or change its type to a Link Construct. 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. Whereas the current construct has no semantics to speak of? But, as mentioned, the spec, modulo bugs, is a done deal at this point. 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. 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
Re: The atom:uri element
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 --Internet Mail Consortium
Re: The atom:uri element
Paul Hoffman, Director, 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. I knew that, but I was unaware of how un-updatable a step that was. I apologize for my ignorance. (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? 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. -- Jimmy Cerra https://nemo.dev.java.net __ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250
Re: The atom:uri element
On Wed, 25 May 2005 06:45:29 +0200, Eric Scheid [EMAIL PROTECTED] wrote: In this instance, I think atom:name, atom:resource, or atom:link works better. +1 atom:link I think atom:[EMAIL PROTECTED] works even better. Thinking of what information is stored in atom:uri and how it is used, why isn't it just an attribute? It's a single value intended for computers, not humans, to parse. The atom:uri element does not have a 'title' attribute or anything else that makes it necessary to keep it as an element, the actual name of the element is awkward in this context and it is not consistent with the rest of the specification to have URI's as text nodes of elements but rather as attribute values (of @src and @href attributes respectively). Consistency makes the format easier to understand and learn. Isn't that something worth stribing (and thus changing) for? -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: The atom:uri element
On 25/5/05 6:57 PM, Asbjørn Ulsberg [EMAIL PROTECTED] wrote: Consistency makes the format easier to understand and learn. Isn't that something worth stribing (and thus changing) for? +1
Re: The atom:uri element
-1 to atom:link unless they are proper link elements. I'm fairly happy with the current situation. Graham
Re: The atom:uri element
On Wed, 25 May 2005 14:53:05 +0200, Graham [EMAIL PROTECTED] wrote: -1 to atom:link unless they are proper link elements. What about atom:[EMAIL PROTECTED], then? I'm fairly happy with the current situation. Okay, but do you agree that the atom:uri element is a bit inconsistent with the rest of the format specification? -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: The atom:uri element
On 25 May 2005, at 2:25 pm, Asbjørn Ulsberg wrote: What about atom:[EMAIL PROTECTED], then? No, I want multiple uris. I've just checked the spec and noticed it doesn't allow them. Why? Shouldn't I be able to have an http: uri and an aim: uri? And couldn't email be a mailto: uri? +1 to replacing atom:email and atom:uri with multiple real atom:link elements (to allow titles). (I don't care about the rel value) Graham
Re: The atom:uri element
On 25/5/05 2:45 PM, Eric Scheid [EMAIL PROTECTED] wrote: I agree with this. I thought it was unusual to name a tag after a specific technology rather than its intent (atom:email is an exception). In this instance, I think atom:name, atom:resource, or atom:link works better. +1 atom:link doh! I was thinking link vs web vs any-damn-name ... totally forgot we already have an element named link. so ... -1 atom:link which is not a Link Construct +1 atom:link which is a Link Construct +1 renaming atom:uri to something semantic instead of some data type +0.5 to making it an attribute, just as we have with atom:generator -1 to leaving it as it is (yes, yes, I know we don't have Link Construct in the spec any more) e.
The atom:uri element
I've mentioned this several times before and haven't had time to follow the evolvement of the draft up until now, but as far as I can tell, atom:uri is still in place in the specification... Do we really need a pace to have that element renamed before the spec goes final? Or is it so that the atom:uri element have many proponents on the list so it can't be renamed or changed to atom:link, atom:email or something making more sense? Even atom:iri is better at this point, imho. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: The atom:uri element
On Tue, 24 May 2005 14:40:41 +0200, Asbjørn Ulsberg [EMAIL PROTECTED] wrote: Or is it so that the atom:uri element have many proponents on the list so it can't be renamed or changed to atom:link, atom:email or something [...] ^^ Just so the replies to this e-mail (if any) doesn't get concentrated around my little mishap with the elements here: I didn't mean writing 'atom:email' there since we already have that element. The point I'm trying to make is not the name of the element, but rather its type. I'd like it to be constructed somewhat similar to atom:link, e.g. be an Atom Link Construct. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: The atom:uri element
Or is it so that the atom:uri element have many proponents on the list so it can't be renamed or changed to atom:link, atom:email or something I agree with this. I thought it was unusual to name a tag after a specific technology rather than its intent (atom:email is an exception). In this instance, I think atom:name, atom:resource, or atom:link works better. Just so the replies to this e-mail (if any) doesn't get concentrated around my little mishap with the elements here: I didn't mean writing 'atom:email' there since we already have that element. The point I'm trying to make is not the name of the element, but rather its type. I'd like it to be constructed somewhat similar to atom:link, e.g. be an Atom Link Construct. Good point. I like the idea of adopting atom:link if several identifiers per person is allowed. Or what about an href or ref attribute on the author element, if only one indentifier is intended per author? Or an about or res attribute if the uri isn't intended to be dereferenceable? Just brainstorming some alternatives. -- Jimmy Cerra __ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs
Re: The atom:uri element
On 25/5/05 2:34 PM, James Cerra [EMAIL PROTECTED] wrote: I agree with this. I thought it was unusual to name a tag after a specific technology rather than its intent (atom:email is an exception). In this instance, I think atom:name, atom:resource, or atom:link works better. +1 atom:link e.
