Subject: Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

From: Henry Story <[email-masked]>
Date: Tue, 1 Mar 2005 11:39:21 +0100

On 20 Feb 2005, at 13:25, Bill de hÓra wrote:
> Graham, Eric,

Ok since the above chickened out of answering your questions above, 
I'll do so
myself.

>
> My thinking goes like this,
>
>  - Is there a difference between an entry and the chunk of XML you see 
> in a feed?

The question is vague and open to many interpretations, but I'd go for 
a yes.

> - If there is, it will be in the same way there is a difference 
> between a resource and a representation in web architecture.

Yes indeed that is the difference as I read it here [3].

> - If you *don't* think a difference exists between an entry and the 
> chunk of XML you see in a feed, there may be things you can't sensibly 
> say [1]. For example if we disallow multiple appearance of an id in 
> one feed we might as well disallow multiple appearance of an id across 
> all feeds, for consistency. That, or document our spec's private 
> definition of the word "unique".
>
> - If you *do* think a difference exists between an entry and the chunk 
> of XML you see in a feed, there may be some practical limitations. For 
> example we will want to ask what's the difference operationally 
> between two Entries that have been assigned the same id and the 
> appearance of two entries with the same in an Atom document that 
> represent the Entry at different states? What's the test that 
> distinguishes between those two cases?

Here you raise a good question. But the way you ask it makes me think 
that
behind this question lurks a deep skepticism on our ability to think
historically at all.

The answer is simple: there is no one unique test. But this does not 
entail
that the distinction is not a perfectly good one that we can use. Think 
about
our historical knowledge.
	How do you know that you are the person with a certain social security
number? You may pull out your social security card, but a skeptic could 
go on to
argue that this card may be forged. Or they could argue that the card 
is real
but that you have taken on the appearance of the person to whom it 
really
belonged. You may then point to all the people around you who have 
known you
for a long time, your school teacher, your family, your friends, etc. 
And this
usually helps a lot, indeed is usually considered to be the basis of 
knowledge
of your identity. You don't get absolute philosophical certainty, but 
you do
get knowledge, even though at each point a case could be constructed in 
which
one was wrong to go by that evidence to reach that conclusion. But this 
is
a well known problem in epistemology, and I would recommend reading the 
late
Robert Nozick's book "Philosophical Explanations" [4] to help 
understand how
to navigate that particular minefield.

So here are some ways you would go about finding out if two entries 
with the
same id (the functional id I keep speaking about, the one that acts the
way a social security number works to identify you):

   - You could simply ask the author if these are the same entry. Did he 
go
  to the earlier representation of the entry by a series of 
transformation steps to
  the later representation? The types of steps one would think of are: 
fixing
  spelling mistakes or grammatical errors, correcting a bad expression 
of the
  thought, ...
   - The author is not the only one to determine the identity of the 
entry.
   Once people start reading and commenting on an entry, they in part 
act to
   constrain what the identity relation of an entry is. An author who 
would
   use completely unpredictable identity relations would confuse his 
readers,
   would reduce the point of replying to his posts or reading them. Ie. 
He would
   make it difficult to distinguish his posts from junk.

> - That we can start sending multiple representations of a resource 
> each marked as so inside another single representation I suspect 
> extends web architecture. I looked and didn't see any support for this 
> idea in AWWW.  Whether it's tunneling, abuse, or a new application 
> layer I don't know.

I suspect that if this had been a problem in web architecture, it would 
have been
noticed long ago. The above seems to be saying that the web can only 
speak about the
present. But it clearly can speak about the past as well. Just check 
out the XML-HR
standard. When I write a resume using that format, I am writing a 
document which describes another resource's (me) history. If one 
suspect that there is something
so fundamentally wrong with web architecture, then this is not the 
forum to discuss
that. One should go to the web arch forums. Here we should assume that 
there is no
such problem. Specialization of tasks demands that.

> - Maybe the WebDAV folks have been through this. HTTP has no obvious 
> use cases or support for serving up resource state in one entity body 
> rather than as a stream of entities.
>
>
> My opinion is that keeping XML representations of entries distinct 
> from entries affords the most flexibility and maximises internal 
> consistency for the kind of use cases feeds support [2]. It will be an 
> arbitrary limitation of language if Atom can't deliver entries with 
> the same id in the same feed - I don't believe that limitation will be 
> respected in practice. It also means we're (possibly) formalizing 
> something for the Web that hasn't been done before.

We seem to be agreeing on which the correct position to take is. But I 
really don't
believe we are doing something that may have implications for web 
architecture.

In any case I have seen no proof that having a feed document with 
multiple entries
with the same id may have any problematic consequences. On the other 
hand it would
be overwhelmingly helpful.

Henry Story

>
> cheers
> Bill
>
>
> [1] I emphasise 'sensibly say' here rather than 'sensibly do'. Just 
> because or spec can't say something doesn't mean people won't try to 
> do it if they think they need to.
>
> [2] I spend a lot of time dealing with identity issues in my job. I've 
> come to believe that neither unique ids or content based identity or a 
> combination of both can eliminate all ambiguities. Sometimes you have 
> to guess whether two things are the same no matter what model you're 
> working with.

[3] http://www.w3.org/TR/webarch/#URI-persistence
[4] http://www.amazon.com/exec/obidos/ASIN/0674664795/qid=1109670853
[5] http://www.xml-hr.org/

---

From: Eric Scheid <[email-masked]>
Date: Tue, 01 Mar 2005 22:25:00 +1100

On 1/3/05 9:39 PM, "Henry Story" <[email-masked]> wrote:

> I'll do so myself.

My apologies: I didn't see the second part of that email. I thought the
extent of Bill's email was the bit addressed to the chairs/editors.

In summary response, I agree with Bill -- entries are resources, <entry>s
are representations. There is a notional construct thing we call an 'entry',
and there is an XML representation of that thing.

The spec shouldn't disallow multiple instances of <entry>s with the same
<id>, however as a compromise I suggest the spec might use the SHOULD
qualifier ... that is, <feed> instances SHOULD NOT have multiple <entry>s
with the same <id>.

What this means is that if you have a good reason to do so, and you realize
that there are a lot of dumb aggregators out there that will choke, and
that's ok by you, then go ahead.

e.

---

From: Henry Story <[email-masked]>
Date: Wed, 30 Mar 2005 14:34:32 +0200

I would just like to revisit this question, because it will help clarify
the "alternate" relation.

On 1 Mar 2005, at 11:39, Henry Story wrote:
>>  - Is there a difference between an entry and the chunk of XML you 
>> see in a feed?
>
> Yes indeed that is the difference as I read it here [1].

I would like to be a little more specific now. If I take the following
entry from the format 06 spec

   <entry>
   <title>Atom-Powered Robots Run Amok</title>
   <link href="http://example.org/2003/12/13/atom03"/>
   <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
   <updated>2003-12-13T18:30:02Z</updated>
   </entry>

Then we can say that the above Entry is a representation of the
<urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a> resource.

Now my current reading of "alternate" is that this Entry representation
had an "alternate" representation at 
<http://example.org/2003/12/13/atom03>
at the time this entry representation was valid (2003-12-13T18:30:02Z)

Future representations of the 
<urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a>
resource may not have an "alternate" representation at that URL.

In which case perhaps the language of the "alternate" relation is a 
little
misleading

[[
The value "alternate" signifies that the IRI in the value of the href 
attribute identifies an alternate version of the resource described by 
the containing element.
]]

I think the above is much stronger than what a lot of people will agree 
to.

If I am reading correctly "the resource described by the containing 
element"
would be the <urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a> resource 
in the
example case.

So that our example xml would be saying that
<http://example.org/2003/12/13/atom03> is an alternate version of 
<urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a>, which is a lot 
stronger than what we want to say, since
we want to allow for domains being hijacked, dying, etc..

I think is much more precise to say that this representation
of <urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a> (the entry above) is 
an alternative representation of <http://example.org/2003/12/13/atom03> 
also.

Here we would be saying something that is true and helpful.

So perhaps the following would be better

[[
The value "alternate" signifies that the containing element is an 
alternative
representation of the IRI in the value of the href attribute.
]]

Henry Story

[1] http://www.w3.org/TR/webarch/#URI-persistence

---

From: Henry Story <[email-masked]>
Date: Thu, 31 Mar 2005 20:07:26 +0200

Just put this forward as a Pace, but have not put it up on the site, as 
there
is less traffic here now.

Abstract:
---------

Weakens the link relation just a wee bit.

Status:
-------
  Open

Rationale
---------

See e-mail below

Proposal
--------

[[

with:

[[

On 30 Mar 2005, at 14:34, Henry Story wrote:
>> The question is vague and open to many interpretations, but I'd go 
>> for a yes.
>>
>>
> I think the above is much stronger than what a lot of people will 
> agree to.
>
> of <urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a> (the entry above) 
> is an alternative representation of 
> <http://example.org/2003/12/13/atom03> also.
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 31 Mar 2005 14:34:20 -0800

> representation of the IRI in the value of the href attribute.

...an alternate representation of the resource identified by the IRI in 
the value...?

--
Mark Nottingham     http://www.mnot.net/

---

From: Henry Story <[email-masked]>
Date: Fri, 1 Apr 2005 01:10:01 +0200

On 1 Apr 2005, at 00:34, Mark Nottingham wrote:
> ...an alternate representation of the resource identified by the IRI 
> in the value...?

yes correct. Thanks for pointing this out.

Proposal
--------
replace

[[

with:

[[
The value "alternate" signifies that the containing element is an 
alternative
representation of the resource identified by the IRI in the value of 
the href attribute.
]]

---

From: Eric Scheid <[email-masked]>
Date: Fri, 01 Apr 2005 09:38:27 +1000

On 1/4/05 9:10 AM, "Henry Story" <[email-masked]> wrote:

> The value "alternate" signifies that the containing element is an alternative
> representation of the resource identified by the IRI in the value of the href
> attribute.

You do realise you've reversed the directionality of the relationship here,
right? 

IMHO, best not to introduce this ambiguity (directionality) into the spec.

Proposal:
--------------------------------------------------------------------------
The value "alternate" signifies that the resource identified by the IRI in
the value of the href is an alternative representation of the resource
described by the containing element.
--------------------------------------------------------------------------

(yes, I know that "alternate" is a commutative bi-di relationship)

e.