I'm a little confused over what's being proposed or counterproposed
here - I thought consensus last year was to break the Web
Whatever, I do think id URIs should be treated as URIs according to
webarch etc - it should be possible to dereference them, assuming
that's supported by the scheme.
On 31 Jan 2005, at 4:22 am, Tim Bray wrote:
OFor ongoing, I plan to use the same http: URIs for both the
atom:id and link rel=alternate; I will manage (and have managed)
my URI space so that they will meet the requirements of permanence,
uniqueness, and so on. In this case the atom:id URI will
On 31 Jan 2005, at 05:22, Tim Bray wrote:
On Jan 30, 2005, at 7:10 PM, Paul Hoffman wrote:
The content of an Identity construct SHOULD NOT be dereferenced,
even when it comes from a
normally dereferencable scheme. There is no requirement for the
content to represent a URI
where a
* Henry Story [EMAIL PROTECTED] [2005-01-31 16:25+0100]
On 31 Jan 2005, at 05:22, Tim Bray wrote:
On Jan 30, 2005, at 7:10 PM, Paul Hoffman wrote:
The content of an Identity construct SHOULD NOT be dereferenced,
even when it comes from a
normally dereferencable scheme. There is
On Sun, 30 Jan 2005 19:28:05 -0800, Mark Nottingham [EMAIL PROTECTED] wrote:
How about Dereferencability of Identity Constructs?
That should discourage most everyone from reading that section.
Lance
On 31 Jan 2005, at 3:40 pm, Tim Bray wrote:
Uh, it seems that you're assuming that can be dereferenced is
equivalent to will be unstable. I disagree. -Tim
I agree it's possible for links to be stable. But giving the id a
functional purpose as an address introduces all sorts of reasons to
H. The dead horse comes to life with more beating. At the risk of
causing further consternation and time-wasting...
At 7:28 PM -0800 1/30/05, Mark Nottingham wrote:
How about Dereferencability of Identity Constructs?
Works for me.
At 10:30 PM -0500 1/30/05, Robert Sayre wrote:
Well, it seems
At 11:47 AM -0500 1/31/05, Robert Sayre wrote:
How about this:
[Last sentence of the first paragraph, combined 3.5.1 and 3.5,
altered first paragraph in Comparing]
3.5 Identity Constructs
An Identity construct is an element whose content conveys a
permanent, universally unique identifier
On Jan 31, 2005, at 8:47 AM, Robert Sayre wrote:
Paul Hoffman wrote:
At 10:30 PM -0500 1/30/05, Robert Sayre wrote:
Well, it seems silly to use a dereferencable scheme if you don't
want the URI dereferenced.
I agree, but there was broad WG consensus on this months ago. It is
too late to revisit
3.5.1 Dereferencing Identity Constructs
The content of an Identity construct MAY be dereferencable (e.g. an
HTTP URI). However, processors MUST NOT assume it to be
dereferencable.
The first sentence doesn't say anything. The second is good but doesn't
go far enough.
The content
At 5:11 PM + 1/30/05, Graham wrote:
3.5.1 Dereferencing Identity Constructs
The content of an Identity construct MAY be dereferencable (e.g. an
HTTP URI). However, processors MUST NOT assume it to be
dereferencable.
The first sentence doesn't say anything. The second is good
a section with this name is asking for
trouble.
We could change it to Not Dereferencing Identity Constructs...
How about Dereferencability of Identity Constructs?
--
Mark Nottingham http://www.mnot.net/
Paul Hoffman wrote:
At 5:11 PM + 1/30/05, Graham wrote:
The content of an Identity construct SHOULD NOT be dereferenced,
even when it comes from a
normally dereferencable scheme. There is no requirement for the
content to represent a URI
where a version of the feed or entry may
On Sun, 30 Jan 2005 22:30:16 -0500, Robert Sayre [EMAIL PROTECTED] wrote:
Paul Hoffman wrote:
At 5:11 PM + 1/30/05, Graham wrote:
The content of an Identity construct SHOULD NOT be dereferenced,
even when it comes from a
normally dereferencable scheme. There is no
On Jan 30, 2005, at 7:10 PM, Paul Hoffman wrote:
The content of an Identity construct SHOULD NOT be dereferenced,
even when it comes from a
normally dereferencable scheme. There is no requirement for the
content to represent a URI
where a version of the feed or entry may be found.
I'm
On 31/1/05 3:22 PM, Tim Bray [EMAIL PROTECTED] wrote:
When using atom:id to ascertain whether two Atom entries or feeds
are the same, such operations MUST be based only on the URI character
strings, and MUST NOT rely on dereferencing the URIs.
+1
16 matches
Mail list logo
