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/




Reply via email to