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 URIs should be treated as URIs according to
webarch etc - it should be possible to dereference them, assuming
that's supported by the scheme.
Th
Ahhh! Here I make the mistake again.
The id relation, relating an Entry and a Identity Construct is
functional, not inverse
functional. Hence an Entry can only have one id relation to a URI of
type identity construct.
But there is a way out of this: if an entry has a number of id
relations, the
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
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
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 that now.
Not what I meant.
Secondly, I fail 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 seem
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
ch
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
* 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 dereferencabl
On Jan 31, 2005, at 6:53 AM, Graham wrote:
Absolutely not Joe times one billion. Any such convention forming
jeopardises the persistence of the identifier, since it will get
changed when people re-organize their site or fiddle with their
features. The id is an identifier and nothing else. Lettin
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 versi
On 31 Jan 2005, at 4:08 am, Joe Gregorio wrote:
I disagree with Graham in that someone may come up with a good thing
to stick at the resource that an Identity construct points at (the
lessons
of XML namespaces not withstanding).
Absolutely not Joe times one billion. Any such convention forming
je
Graham wrote:
The content of an Identity construct SHOULD NOT be dereferenced,
Graham,
Would you go with "..MUST NOT rely on dereferencing.." instead?
cheers
Bill
On 31 Jan 2005, at 4:22 am, Tim Bray wrote:
OFor "ongoing", I plan to use the same http: URIs for both the
and ; 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 URI will absolutely
be dereferenced, b
On 31/1/05 3:22 PM, "Tim Bray" <[EMAIL PROTECTED]> wrote:
> "When using 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
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 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 schem
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
think even having 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/
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 goo
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
21 matches
Mail list logo