Semantics and Belief contexts - was: PaceDuplicateIdsEntryOrigin posted
On 25 May 2005, at 21:06, Antone Roundy wrote: * The accepted language does not speak of the origin feed of the entries. Ideally, an atom:id should be univerally unique to one entry resource, and we rightly require publishers to mint them with that goal. However, in reality, malicious or undereducted publishers might duplicate the IDs of others. Therefore, it is proposed to modify the specification to state that the atom:entry elements describe the same entry (resource) if they originate in the same feed. * Aggregators wishing to protect against DOS attacks are not unlikely to perform some sort of safety checks to detect malicious atom:id duplication, regardless of whether the specification authorizes them to or not. I understand your motivation, but I think it is misguided. I only recently understood why myself [1]. Let me explain a little how I come to this conclusion. An easy way to understand semantics is to think of it as about the objects out there. Take the sentences: (a) Superman can fly (b) Superman is Clark Kent we can immediately deduce truly that (c) Clark Kent can fly. Since the referents of Superman and Clark Kent are the same, what is true of the one, is true of the other. When speaking directly about the world, we can replace any occurrence of Superman with Clark Kent, and still say something true. When we are speaking about what others believe, this is no longer true. Lois Lane may believe (a) without believing (c). She may think Superman is a hero, but not think that Clark Kent is one. There is in logic therefore a fundamental distinction between sentences used in a direct semantic way, and sentences used in this indirect way, when the sentence is in a belief context. This distinction is so fundamental that there is a well known mental illness that goes with people who are not able to make this distinction: autism. Autistic children have great difficulty understanding the difference between what is and how people perceive things to be. In RDF this distinction shows up when moving from triples to 4- tuples. RDF/XML is a language that works best in the Semantic realm. With triples we can describe objects and their relationships. If we want speak about consistent ways of seeing the world we need to group statements with formulae as is done in N3[2] and TriX for example. This then allows us to name consistent sets of statements. It also allows one to simultaneously refer to sets that are inconsistent. I can for example consistently hold the following: Lois lane believes that Superman is different from Clark Kent Clark Kent believes that he is Superman. without contradiction. So how does this relate to Atom? Well we need to be clear that semantically a entryId and a feedId point to one thing and one thing only. But this does not mean that there can not be erroneous, false, corrupted,... feeds out there. Aggregators wishing to protect against DOS attacks should simply do what we humans do in such circumstances, namely quote what others are saying and not assert the things others are saying. This is why the proposal by Roy Fielding to allow feeds inside of feeds was probably the best way to do things (I just came to this conclusion yesterday, before this I had no idea what he was going on about). So to prevent a DOS attack, best is to have aggregator feeds such as: feed !-- aggregator feed -- feed src=http://true.org; idtag://true.org,2005/feed1/id entry titleEnter your credit card number here/title ... /entry /feed feed src=http://false.org; idtag://true.org,2005/feed1/id entry titleEnter your credit card number here/title ... /entry /feed /feed Here all the aggregator feed is claiming is that he has seen entries inside other feeds. He never need claim to agree with any of their content. And so the content of the first internal feed and the second internal feed can be contradictory. They can for example have the same id with the same updated timestamp and with different content. It will be up to the consumer of such aggregated feeds to decide which to trust. The good thing about this way of doing things is that one can define a first level feed in a simple semantic vocabulary, without needing to create all kinds of exceptional clauses all over the place. When dealing with feeds inside a feed one can then simply mention that this indirection is equivalent to the belief context indirection. Statements can be contradictory across such internal feeds. Taking this into account should help make the spec a lot cleaner, easier to write and easier to understand. The problems are fundamental, so they cannot be swept under the carpet. They will keep popping up. Henry Story [1] http://www.imc.org/atom-syntax/mail-archive/msg15608.html [2] http://www.w3.org/DesignIssues
Re: Refresher on Updated/Modified
My thought currently is that atom:updated by being the sole date in atom is in fact what people are thinking of as atom:modified. It is just specified very flexibly and constrained not by language but by how it will be used. The game of publishing entries will push people to be reasonably precise about what they consider to be a change: - if they don't, their entries may be lost - creating a new time stamp is so easy, there is no reason not to change the time stamp by default So I am in fact -1 on atom:modified. It would be silly to have 2 dates in atom, we would then just have more confusion and corner cases. The more precise date would inevitably be considered the real one, and the other one ignored in any case. Adding a more precise definition of what constitutes a change is beyond the ability of this working group given the way it has to come to an agreement. On 24 May 2005, at 01:17, David Powell wrote: When a publisher updates an existing entry, the value that they put in atom:updated combines three parameters: a) The last modified date of the entry (ie: the value that would go into atom:modified if it existed) b) The atom:updated value of the previous instance. c) Whether the publisher's opinion is that the change is significant. (some publishing systems may not allow the publisher to express this opinion - in that case, this parameter will be hard-coded) The publisher chooses whether the new atom:updated value should be the current modification date, or the previous atom:updated value based on whether, in their opinion the change is significant. If a publisher wants to change an entry, and wants to indicate that in their opinion the change was not significant, the current draft allows them to do this by publishing a new version of the entry with the same value of atom:updated as the previous version.
Re: inheritance issues
Simplify, simplify. I am for removing all inheritance mechanisms... Henry On 24 May 2005, at 02:02, Bill de hÓra wrote: Eric Scheid wrote: oh darn. This damn inheritance stuff is nasty. Inheritance suggests a programming model to allow the evaluator to be coded for it. It's rarely as simple as it looks to define a decent model that does what people think it does at first glance. As things stand, it will be an immense coincidence if we do not end up dishing out nasty surprises for users. Atom's just not a very good programming language ;) cheers Bill
Re: Author and contributor
On 23 May 2005, at 07:22, A. Pagaltzis wrote: In [EMAIL PROTECTED] (http://www.imc.org/atom-syntax/mail-archive/msg15517.html), Antone Roundy suggests: make atom:author plural keep atom:contributor punt bylines to an extension +1 to all I think that makes sense, especially if one thinks that atom could be used for wiki entries, where there being numerous authors is a fact of daily life. Henry
Re: updated and modified yet again
On 22 May 2005, at 06:29, Tim Bray wrote: News flash! Bob and I agree! I have been following this discussion and am finding I am also agreeing with Tim, Bob and Aristotle P. The points are subtle. This made me wonder if the points are not playing themselves out a different level. Perhaps the problem is that we are not clear about the difference between semantics and what is being said. At the level of semantics an entry as identified by its id has a number of dated representations. These representations can be grouped in different ways according to different identity criteria. One very precise such identity criteria would be string identity. Two representations are identical if they are character by character identical. Another identity criteria, lets call it update identity, says that two such representations are equivalent if they have the same atom:updated time stamp. This is a very vague identity criterion, which leaves it up to the interaction between users and consumers to set constraints on the criterion. The user has to face the fact that consumers may drop some of his changes (conceived of as changes under the criterion of string identity) if he does not change the date. So let us think of this from the point of view of the three players in this game: the original publisher, the final consumer, and the intermediary. The original publisher -- When the publisher is the same person as the person defining the identity criteria, then it makes sense that he should not publish two entries in a feed that are identical according to his own criteria. This can not be conceived to be a restriction on him. The final consumer -- The final consumer may have different identity criteria to the publisher of the feed, but since he is not the one to publish the feed there is not much for him to do. He cannot force the original publisher to be more precise, because that would be to ask the person who is publishing to see a distinction where he sees none. And this does not even take into account that other consumers may disagree with him anyhow. The aggregator -- The problematic case comes from those aggregating feeds. And I think here I can identify two different problems: a- The aggregator may say he has different identity criteria from the publisher. If he has then one can simply answer: your business is to be transparent, not to place yourself in between your user and his public. b- The aggregator wants to be completely transparent. But has a problem because he is not sure who to trust, and different people are making different claims about the same thing (the id). In everyday life there is a well known method for doing this honestly: we quote the source of who said what. If Smith says that the red car is his and John says that the car is his, I don't need to say that the car belongs to Smith and to John, I can just say Smith says that 'the car is his' and John says that 'the car is his'. I just need to quote what others have said. If this is the problem faced by Bob then I don't think atom:modified is going to help. That would be being precise in the wrong place. What would have helped was perhaps the solution proposed by Roy Fielding a few months ago, namely that a feed should be able to contain a feed. Bob's pub sub service would then be just able to quote what others (feeds) have said. It would then have been correct to hold the position currently held that no feed should *directly* contain an entry with the same atom:updated value. It would allow that a feed could contain two feeds each with different entries containing the same id and the same atom:updated time stamp. It would then be up to the consumer to decide which one it trusts. Henry Story
Re: atom:modified indicates temporal ORDER not version....
I just found an excellent article on the subject of identity: http://plato.stanford.edu/entries/identity/ It is heavy reading. But it does give an excellent overview of the subject. I can't say that I managed in a couple of hours to fully digest all the information in there. Henry On 22 May 2005, at 02:51, Robert Sayre wrote: On 5/21/05, Henry Story [EMAIL PROTECTED] wrote: On 22 May 2005, at 02:27, Robert Sayre wrote: On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote: Robert Sayre wrote: Temporal order of what? They are all the same entry, so what is it you are temporally ordering? We are discussing the temporal ordering of multiple non- identical *instances* of a single Atom entry. It is common in the realm of software engineering to deal with this concept of instances. Things are often considered to be simultaneously different and the same. (I am who I am today -- as I was when I was a child, nonetheless, I am very different today than I was when I was a child. The instance of me today differs from the instance of me that you might have come across many years ago.) But, perhaps this concept is too abstract for some readers... I'm unconvinced. Have a giant -1. How can you be unconvinced about something so fundamentally basic to human thought? People change over time. When you clip your nails your body is not the same as it was before, yet as far as the law is concerned, you are the same person who went to whatever school you went to. Change over time exists. For something to be able to change there has to be something that is the thing that changes. Really you can't get more basic than this. If you are left to argument over this, I would suggest moving your discussion over to a philosophy forum. Gee, Henry, maybe you should draw us a UML diagram to explain all this. Robert Sayre
Re: Accidental and intentional atom:id collisions
On 18 May 2005, at 17:30, Antone Roundy wrote: On Wednesday, May 18, 2005, at 09:12 AM, Henry Story wrote: I supposed the surest way to make it impossible to fake the id, is to specify that by dereferencing the id and doing a GET (whatever the correct method of doing that for the protocol happens to be) one should be able to retrieve the entry. The unlikelihood of anyone actually retrieving each entry to verify that it's accurate would make this method only trivially effective. Perhaps not. There was a long thread a few months ago about how to deal with the growing size of feeds. Using a restful method, one simple solution to the problem would have been to have minimal feeds of the following form: feed idhttp://a.com/feeda/is entry idhttp://a.com/feeda/entry1/id updated2005-01-01T05:00+00:00/updated /entry entry idhttp://a.com/feeda/entry2/id updated2005-01-02T06:00+00:00/updated /entry entry idhttp://a.com/feeda/entry3/id updated2005-01-03T07:00+00:00/updated /entry /feed Clearly feeds like the above would only be useful if one dereferenced the entry ids. A consumer of an atom feed would thus read a feed, then work out which of the entries it had not yet seen or which had been modified, and then go and fetch the content of those entries by dereferencing the id. In the above case this could be done by doing a GET on http://a.com/feeda/entry1 for example and retrieving entry idhttp://a.com/feeda/entry1/id updated2005-01-01T05:00+00:00/updated titleI am the legitimate entry/title content type=htmllt;a href=https://a.com/ feedback.phpgt;Use this form to submit your credit card numberlt;/ agt;/content /entry Of course the above saves a lot more bandwidth the larger the entry becomes. An oddity this language introduces is that if the entries don't appear in the same Atom Feed Document, they apparently don't have to be treated as the same entry, but if they're aggregated together, they do. Going a little further, if I'm subscribed to both original feeds and an aggregation that includes both, then I have potentially four entrys with the same id. Which are the same entry and which aren't? Only the two in the aggregation, which really aren't, are required to be treated as the same. I always thought that two entries with the same id should be treated as the same entry. What makes you thing otherwise? Consider the following three simplified feed documents (or any two of them, or just the last one): // this is the legitimate one Yes but now imagine the same thing written in the minimal format menitoned above: feed idhttp://a.com/feeda/id entry idhttp://a.com/feeda/entry1/id updated2005-01-01T05:00+00:00/updated titleI am the legitimate entry/title content type=htmllt;a href=https://a.com/ feedback.phpgt;Use this form to submit your credit card numberlt;/agt;/content /entry /feed !-- the original feed -- feed idhttp://a.com/feeda/id entry idhttp://a.com/feeda/entry1/id updated2005-01-01T05:00+00:00/updated /entry /feed // this one is phishing feed idhttp://b.com/feedb/id entry idhttp://a.com/feeda/entry1/id updated2005-01-01T10:00+00:00/updated titleI am the legitimate entry/title content type=htmllt;a href=https://b.com/ feedback.phpgt;Use this form to submit your credit card numberlt;/agt;/content /entry /feed !-- the phishing feed -- feed idhttp://a.com/feedb/id entry idhttp://a.com/feeda/entry1/id updated2005-01-01T05:00+00:00/updated /entry /feed // this is an aggregation feed idhttp://c.com/feedc/id entry source idhttp://a.com/feeda/id /source idhttp://a.com/feeda/entry1/id updated2005-01-01T05:00+00:00/updated titleI am the legitimate entry/title content type=htmllt;a href=https://a.com/ feedback.phpgt;Use this form to submit your credit card numberlt;/agt;/content /entry entry source idhttp://b.com/feedb/id /source idhttp://a.com/feeda/entry1/id updated2005-01-01T10:00+00:00/updated titleI am the legitimate entry/title content type=htmllt;a href=https://b.com/ feedback.phpgt;Use this form to submit your credit card numberlt;/agt;/content /entry /feed !-- the aggregation feed -- feed idhttp://a.com/feedc/id entry source idhttp://a.com/feeda/id /source idhttp://a.com/feeda/entry1/id updated2005-01-01T05:00+00:00/updated /entry entry source idhttp://a.com/feedb/id /source idhttp://a.com/feeda/entry1/id updated2005-01-01T05:00+00:00/updated /entry /feed Notice that the source of an entry is much less important in this situation
Re: Accidental and intentional atom:id collisions
On 21 May 2005, at 08:44, Eric Scheid wrote: On 21/5/05 4:24 PM, Henry Story [EMAIL PROTECTED] wrote: So those are just a few thoughts on the topic. It just seems that if one works with the web these phishing problems seem to disappear. all good stuff, with the exception of making atom:id dereferenceable... once you do that you have to allow it to change (to accommodate changes in server set up etc), and once you allow it to change it is no longer effective as an id :-( Yes. I like the idea of being able to move entries around too. But we do have a dilemma. We have a- non de-referenceable id: - can easily be faked - lack of trust which undermines its ability to identify anything b- de-referenceable id: - we can't move entries around - but we can trust the id Imagine we have both (as we do, but in a more cumbersome format). If we give the entry a src attribute then we could have a feed such as the following: feed idhttp://a.com/feeda/is entry src=http://a.com/feeda/entry1; idurn:uuid:1225c695-aaa-4ebb--80da344efa6a/id updated2005-01-01T05:00+00:00/updated /entry entry src=http://a.com/feeda/entry2; idurn:uuid:2225c695-bbb-4ebb--80da344efa6a/id updated2005-01-02T06:00+00:00/updated /entry entry src=http://a.com/feeda/entry2; idurn:uuid:3225c695-ccc-4ebb--80da344efa6a/id updated2005-01-03T07:00+00:00/updated /entry /feed Then since the ids can be faked and spoofed all over the place, and since there is no way to automatically verify the correct uses, the amount of trust that can be placed in them to identify an entry is minimal, close to 0, certainly a *lot* less than the dereferenceable src uri, which will therefore inevitably take the place of the identifier. So in any case it seems like the dereferenceable id wins. Perhaps this is just something in the architecture of the web that we have to work with. But perhaps it is not such a problem after all, because perhaps we can have dereferenceable ids that allow us to move entries around. I can think of a few: - if an entry moves the old entry position redirects to the new one. - one creates a special redirect service to redirect ids to their current location - one creates a new URI to URL mapping protocol Henry Story So, all the above, but using atom:[EMAIL PROTECTED]'self'] instead. BTW, /feed/id is useful for other things -- primarily to help big aggregators to realise that they are retrieving the same feed from more than one location (eg. with and without www.) e.
Re: atom:modified indicates temporal ORDER not version....
On 22 May 2005, at 01:27, Robert Sayre wrote: On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote: Robert Sayre wrote: So, it's about disambiguating versions of an entry, right? No. It has nothing to do with versions or even variants. I have explained that on numerous occasions. The denial of relevance to the issue of version is even in the title of this thread. Read: atom:modified indicates temporal ORDER not version... Clearly, you either aren't reading what you're responding to or you simply don't understand what is written Temporal order of what? They are all the same entry, so what is it you are temporally ordering? You are temporally ordering states of the entry. Or if you think of the id as the resource for which the entry.../ entry text is a representation, then you are ordering the representations sequentially/temporally. Why is this a new problem that only arises when we allow multiple IDs in the same feed? I don't think this is a problem that only arises when we allow multiple ids in the same feed. Henry Robert Sayre
Re: atom:modified indicates temporal ORDER not version....
On 22 May 2005, at 02:27, Robert Sayre wrote: On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote: Robert Sayre wrote: Temporal order of what? They are all the same entry, so what is it you are temporally ordering? We are discussing the temporal ordering of multiple non- identical *instances* of a single Atom entry. It is common in the realm of software engineering to deal with this concept of instances. Things are often considered to be simultaneously different and the same. (I am who I am today -- as I was when I was a child, nonetheless, I am very different today than I was when I was a child. The instance of me today differs from the instance of me that you might have come across many years ago.) But, perhaps this concept is too abstract for some readers... I'm unconvinced. Have a giant -1. How can you be unconvinced about something so fundamentally basic to human thought? People change over time. When you clip your nails your body is not the same as it was before, yet as far as the law is concerned, you are the same person who went to whatever school you went to. Change over time exists. For something to be able to change there has to be something that is the thing that changes. Really you can't get more basic than this. If you are left to argument over this, I would suggest moving your discussion over to a philosophy forum. Henry Robert Sayre
Re: Accidental and intentional atom:id collisions (was Re: Consensus call on last raft of issues)
On 18 May 2005, at 16:41, Antone Roundy wrote: On Tuesday, May 17, 2005, at 11:07 PM, Sam Ruby wrote: If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they describe the same entry and software MUST treat them as such. IIRC, much of this started due to an objection by Bob Wyman that treating atom:entries from different sources with the same atom:id as the same entry would cause problems for PubSub. What ever happened to that objection? This is the one remaining issue I'm aware of that I think we really need to resolve. Until mankind evolves to the point that DOS attacks are no longer attempted, we need to try to protect against them. A MUST here goes beyond just allowing DOS attacks, it's practically an invitation: copy the target entry, increment atom:updated, change a few critical details, publish. How can an aggregator protect against this without violating the spec? I supposed the surest way to make it impossible to fake the id, is to specify that by dereferencing the id and doing a GET (whatever the correct method of doing that for the protocol happens to be) one should be able to retrieve the entry. This I know goes against some of the hopes built into id, but I think that it may be that this is the cost of working in on the web. You just can't escape REST. An oddity this language introduces is that if the entries don't appear in the same Atom Feed Document, they apparently don't have to be treated as the same entry, but if they're aggregated together, they do. Going a little further, if I'm subscribed to both original feeds and an aggregation that includes both, then I have potentially four entrys with the same id. Which are the same entry and which aren't? Only the two in the aggregation, which really aren't, are required to be treated as the same. I always thought that two entries with the same id should be treated as the same entry. What makes you thing otherwise? Henry Story http://bblfish.net/blog/
Re: PaceAllowDuplicateIdsWithModified
Should one not then to make atom:update a MAY? We don't really need 2 MUST dates. Henry On 16 May 2005, at 00:12, David Powell wrote: PaceAllowDuplicateIDs received some opposition because of its use of atom:updated to differentiate multiple revisions of an entry [1][2] [3]. I've posted a couple of Paces - basically a single a proposal, split into two bite-size pieces: http://intertwingly.net/wiki/pie/PaceAllowDuplicateIdsWithModified http://intertwingly.net/wiki/pie/PaceDateModified2 Apologies in advance. I know what happened last time we discussed dates, and this is hardly the best timing, but it seemed like an obvious fix for the problem. [1] http://www.imc.org/atom-syntax/mail-archive/msg14738.html [2] http://www.imc.org/atom-syntax/mail-archive/msg14750.html [3] http://www.imc.org/atom-syntax/mail-archive/msg15144.html -- Dave
Re: atom:updated vs entry inheritance?
On 12 May 2005, at 23:22, Eric Scheid wrote: On 13/5/05 7:12 AM, Henry Story [EMAIL PROTECTED] wrote: Just to recapitulate: we have 2 feed documents with successive atom updated values, and with the same entry (same id) with the same time stamp but some values that are not identical. Does the newer feed document trump the older one? I assume what you mean by values includes the explicit elements of the entry *plus* the implicit elements inherited from the feed. Right? Oh. I understand your puzzle now (reading this list a little fast at times) I had forgotten about inheritance. The simplest solution is just to remove these inheritance rules of course. Henry It follows then that /feed/updated applies *only* to the feed meta- data, and possibly also the feed entries as a collection of opaque blobs. That is, the contents of the entries don't inherit any 'significant change' semantic from /feed/updated. Best practice then would be to update /feed/entry/updated if an inherited /feed/element is updated 'significantly'. I'm happy with that. e.
Re: PaceAllowDuplicateIDs
Don't you have the same problem with atom:modified? What if the publisher does not update the atom:modified entry? I suppose that if you are making an archive of an atom entries and believe that the author has made a mistake with the atom:updated field, you can of course try to correct the mistake artificially in your own feed by increasing the time precision. So if the original entries both claim to have been updated at 12:45 you could have one of them be modified at 12:45:30 and the other at 12:45:31. Just a thought. Henry Story On 12 May 2005, at 01:40, David Powell wrote: I'm in favour of allowing duplicate ids. This only seems to be a partial solution though: Their atom:updated timestamps SHOULD be different But what if they are not? What if I want to represent an archive of a feed - maybe mine, maybe someone else's - but the atom:updated dates are the same in two or more entries? I thought it was up to the publisher to decide whether to rev atom:updated. I was always concerned that the existence of atom:updated without atom:modified would cause the meaning of atom:updated as an alert to be diluted to being equivalent to atom:modified. This proposal would encourage that. It would mean, if you don't update atom:updated, then your entry instances are second class. The restriction forces services that proxy, or re-aggregate feeds to drop entries on the floor, just because the user has chosen not to update atom:updated. atom:updated encourages aggregators to make loud noises when they see a change; anything that encourages atom:updated to be changed just for the sake of it is going to be very annoying to users and make atom:updated useless as an alert flag. I'm in favour of duplicate ids, but unfortunately, the only way I can see them working is if we have atom:modified. I hate to bring this up, especially now, but it would solve some problems, and it is cheap to implement: Is anyone still opposed to atom:modified? -- Dave
Re: atom:updated vs entry inheritance?
On 12 May 2005, at 18:49, Eric Scheid wrote: On 13/5/05 2:04 AM, Roger B. [EMAIL PROTECTED] wrote: Gah! What is the true atom:updated for the following entry? Eric: The entry-level version, IMO. What if an atom processor had previously seen that entry with that atom:updated ... should it do anything with it? Should it update it's local store in any way? What if the /atom:feed/atom:author element had been changed (and the publisher thought that was significant)? Just to recapitulate: we have 2 feed documents with successive atom updated values, and with the same entry (same id) with the same time stamp but some values that are not identical. Does the newer feed document trump the older one? Does this not all depend whether you are an optimist or a pessimist? The optimist will think that the future is always an improvement over the past, and so think that the new feed he has received will be giving a correction on the old state of the entry. The pessimist will think that the future is worse than the present, and think that the newer version of the feed documents must contain a mistaken entry. Henry e.
Re: PaceFeedIdOrSelf
On 10 May 2005, at 04:23, Antone Roundy wrote: On Monday, May 9, 2005, at 07:52 PM, Eric Scheid wrote: rel=self is in no way a substitute for an identifier Why not? the uri can change. Yes, I acknowledged that a little after why not?. So we have a tradeoff--greater permanence vs. greater resistance to spoofing. In my opinion, protection against spoofing is more valuable, in part because I expect most feed URIs to be stable enough that their changing won't be a significant issue. Also because things like the volume of SPAM that gets sent to me convince me that people WILL exploit atom:id's spoofability to DOS others' entries. I'm open to experience and reasoning to the contrary, but at this point, that's my position. I am starting agree a little hesitantly with that position. For either a feed or an entry there has to be a url that is used to DELETE, PUT, or GET it. These actions being available automatically give clients a handle on the identity of the resource. If the id is just a string to be shoved around with no means of verifying it in this way, making it possible to be spoofed, then all trust in it will vanish and inevitably the role of identity will go to whatever enables actions such as DELETE, PUT and GET. Now perhaps in a p2p world it makes sense to GET a url such as tag:example.org,2003:3.2397 and so that our language is just being open to new protocols. (Can a P2P network allows PUTs and DELETE on such a url?) I say I am agreeing hesitantly, because the idea of having an id that would allow one to move one's feed or entry from one server to another seems very appealing. But perhaps there will be other methods of noting such a move that will be more effective. One such way would be for the old moved url to send http redirects to the new one. One could also choose one's blog service provider by asking for a contract where they agree to provide such a redirect on all one's entries in case one wishes to move. Henry
Re: PaceAllowDuplicateIDs
If I can summarize your point: You prefer applications that only allow one entry with the same id per feed. Those that don't should use a different format that has not been defined yet. This seems little weak an argument to me. I think we should permit certain types of communication to take place. The applications and the consumers should decide which are the most helpful to them at the time. More details below... On 8 May 2005, at 08:20, Martin Duerst wrote: At 00:12 05/05/07, Bob Wyman wrote: Right. We have abstract feeds and entries and we have concrete feeds and entries. The abstract feed is the actual stream of entries and updates to entries as they are created over time. Feed documents are concrete snapshots of this stream or abstract feed of entries. An abstract entry is made concrete in entry documents or entry elements. An abstract entry may change over time and may have one or more concrete instantiations. Some applications are only interested in being exposed to those concrete entries that reflect the current or most recent state of the abstract entries -- these apps would prefer to see no duplicate ids in concrete feed documents even though these duplicates *will* occur in the abstract feed. Other applications will require visibility to the entire stream of changes to abstract entries -- these applications will wish to see concrete feeds that may contain multiple, differing concrete instantiations of abstract entries. i.e. they will want the concrete feed to be an accurate representation of the abstract feed. Two needs, to views... You say 'some applications' and 'other applications', as if they were on the same footing. In my view, the 'some applicaitons' (only interested in latest version) should be the usual case, and the 'other applications' (interested in more than one version) should be the exception. One does not need to rule what most types of applications will be most common by making a ruling on the format of the spec. Pragmatics will work for you very well: - It takes work to keep an archive of the past. As a result archives will be less common. - Most people are interested in current changes, as opposed to past changes Most applications will therefore work to satisfy current users needs, and so again feeds with multiply entries with the same id will be rarer. Mapping that back to the origin, applications generating feeds that in one way or another rely on the user getting more than one, or more than the latest, versions of their entries have made a design error, they have taken the wrong thing for the 'entry'. If they think that they have two different kinds of audiences, interested in two different things, they should publish two feeds. Exactly. There is no need to have two formats, an archive format and a feed format. Let applications just create two feeds for the different uses that are made of them. Some people claim that we need a definition for 'entry' to finish this discussion, but once we confirm that a feed can only contain one version of an entry with the same ID, the definition of entry is as clear as we need it to be. Sorry to pick a nit, but that may help in giving one an understanding of what a feed is, but not of what an entry is. This is just the same as for Web pages. If somebody puts up a Web page for the current weather, there is nothing in HTTP that will help me get the past versions of this page. ((Note: Nothing stops browser from keeping a history of every url you have ever seen though. I for one would find such a browser at times extremely useful. We are what we read and see on the internet. Being able to keep track of changes would help reduce the danger of the Orwellian rewriting of history.)) If the publisher thinks that people may be interested in past weather info, they will make up separate pages. But there is nothing in these separate pages that says that they are two versions of the same thing. This point is clearer with the wiki example. As wikis change one can put the old versions of the wiki at separate urls. But there is nothing to say in HTTP that these are two versions of the same content, one older that the other. What a collection of entry representations with the same id give us is the notion of identity (and so change) over time and across uris. This is a really important and useful concept. If we think that it would be valuable to be able to correlate the entries in both feeds, we should define an extension for that, not mess around with the basic model. An extension would be rather easy, we only need two rel values for links in entries. One rel value could be called permaentry, the other could be called updatingentry. Maybe a third called updatingfeed, if there is an updating feed for a single changing entry. I'm sure there are better names. Yes. I agree. We can write an extension to name the particular states (that are currently anonymous) and give pointers to a resource
Re: entry definition
On 8 May 2005, at 16:35, Graham wrote: On 7 May 2005, at 1:35 pm, Henry Story wrote: My definition is making me wonder whether I should not in fact accept that link alternate is a MUST. Not really. There's no reason why the resource an Atom entry describes has to be visible online anywhere else. yes. I suggested that perhaps one could think of the atom entry as being about itself in that case. Perhaps that is circular. But perhaps not. Think of an entry id such as http://test.net/blog/ entry1 This could have two representations: -an atom entry representation -a simple html representation One could think of the atom entry as being about the representation that would be returned by fetching the same resource with a text/html mime type An Atom Entry is a resource (identified by atom:id) whose representations (atom:entry) describe the state of a web resource at a time (the link alternate) But in theory there's a one-to-one relationship between atom:id and the resource being described, and not between it and the link alternate (eg Alternate versions of several entries may all appear on the same webpage). This makes more sense to me: An Atom Entry is a resource whose representations (atom:entry) describe the state of a resource (identified by atom:id) at a time. That is true by definition of the atom:entry representations being representations of the atom:id resource. Representations of a resource are always descriptions of the resource they are representations of. That's the whole point of the resource/ representation distinction. So we agree that atom:entry representations are representations of the atom:id resource. But what I thought interests us (humans) about these representations is that they contain information about the state of some other resource(s) (the link alternate). The entry is a collection of metadata (where the content can also be metadata), about the link alternate. But perhaps I am wrong here. Perhaps an entry is just metadata (about the atom:content?). And the time stamp atom:updated is the time at which all that metadata was changed (and so thought to be correct). [One or more alternate representations of that resource may also be available (link alternate)] The part in square brackets isn't really part of the definition of an entry. The at a time not having an associated element bugs me. It's too late now, but we really should have had a When was this snapshot taken? date element. I think there is in fact such a time element. - If the atom:id is a simple http url and can be dereferenced then the time of the snapshot would be the time you fetched the representation. - if the atom:id is a undereferenceable uri such as uri:urn:... then it usually will come in another packet, eg a feed, which will have been fetched from the web. One could use that time stamp, if one fetches it oneself, or even better, one could use the atom:updated field of the feed. I wonder if this exercise has been much help now. Henry Graham
Re: Blogged and RDF
On 8 May 2005, at 21:43, Reto Bachmann-Gmuer wrote: back home and looking at the code: could you give me a hint on how to get the instances of AtomContent given a com.sun.labs.tools.blog.Blog or org.openrdf.model.Graph (I was looking at the SesameRDFFactory). Well you can get all instances of a particular class in the database by using the SesameRDFFactory.getAllObjects(AtomContent.class) This gets set up in the Blog class. Currently I find it is best to make sure all the classes are set up in the database with a call similar to Blog.initFactory(). a good example is the Blog.getEntries() method. There is still a lot of clean up to do in this SesameRDFFactory class. I have let it grow up till now so that it would fit my needs. But I have some good ideas on how to clean it up. As you see I have a whole bunch of implementations of my interfaces such as AContent, which I use to create objects and testing them for coherence before adding them to the database. Clearly one could just as well create them as dynamic proxies. But when I started writing this I was not sure if that would give me all I needed. I don't believe anymore that one should return classes with more interfaces implemented that what the class returns. I think instead that there should perhaps be a RDFFActory cast() method that returns an object with extra interfaces implemented. Though I am still not sure about this. Henry thanks! reto
entry definition
Some have been clamoring for a good definition of an entry. Here is one I have thought of recently. An Atom Entry is a resource (identified by atom:id) whose representations (atom:entry) describe the state of a web resource at a time (the link alternate) Any thoughts? Henry
Re: PaceAllowDuplicateIDs
Tonight something incredible happened to me. You won't believe it. I was walking back from the pubs when I got snapped by a passing space ships full of hyper advanced aliens. They did various experiments on me, and cloned me 1000 times. It is terrible. I just don't know what to do. I suppose that I means am +1000 on this now. :-) That's consensus, I am sure. Henry http://bblfish.net/blog/ On 5 May 2005, at 06:02, Tim Bray wrote: co-chair-hat status=OFF http://www.intertwingly.net/wiki/pie/PaceAllowDuplicateIDs This Pace was motivated by a talk I had with Bob Wyman today about the problems the synthofeed-generator community has. Summary: 1. There are multiple plausible use-cases for feeds with duplicate IDs 2. Pro and Contra 3. Alternate Paces 4. Details about this Pace 1. Use-Cases Here's a stream of stock-market quotes. feedtitleMy Portfolio/title entrytitleMSFT/title updated2005-05-03T10:00:00-05:00/updated contentBid: 25.20 Ask: 25.50 Last: 25.20/content/item /entry entrytitleMSFT/title updated2005-05-03T11:00:00-05:00/updated contentBid: 25.15 Ask: 25.25 Last: 25.20/content/item /entry entrytitleMSFT/title updated2005-05-03T12:00:00-05:00/updated contentBid: 25.10 Ask: 25.15 Last: 25.10/content/item /entry /feed You could also imagine a stream of weather readings. Bob's actual here-and-now today use-case from PubSub is earthquakes, an entry describes an earthquake and they keep re-issuing it as new info about strength/location comes in. Some people only care about the most recent version of the entry, others might want to see all of them. Basically, each atom:entry element describes the same Entry, only at a different point in time. You could argue that in some cases, these are representations of the Web resources identified by the atom:id URI, but I don't think we need to say that explicitly. Yes, you could think of alternate ways of representing stock quotes or any of the other use-cases but this is simple and direct and idiomatic. 2. Pro and Contra Given that I issued the consensus call rejecting the last attempt to do this, which was PaceRepeatIdInDocument, I felt nervous about revisiting the issue. So I went and reviewed the discussion around that one, which I extracted and placed at http://www.tbray.org/tmp/ RepeatID.txt for the WG's convenience. Reviewing that discussion, I'm actually not impressed. There were a few -1's but very few actual technical arguments about why this shouldn't be done. The most common was Software will screw this up. On reflection, I don't believe that. You have a bunch of Entries, some of them have the same ID and are distinguished by datestamp. Some software will show the latest, some will show all of them, the good software will allow switching back and forth. Doesn't seem like rocket science to me. So here's how I see it: there are plausible use cases for doing this, and one of the leading really large-scale implementors in the space (PubSub) wants to do this right now. Bob's been making strong claims about not being able to use Atom if this restriction remains in place. I believe strongly that if there's something that implementors want to do, standards shouldn't get in the way unless there's real interoperability damage. I'm certainly prepared to believe that this could cause interoperability damage, but to date I haven't seen any convincing arguments that it will. I think that if we nonetheless forbid it, people who want to do this will (a) use RSS instead of Atom, (b) cook up horrible kludges, or (c) ignore us and just do it. So my best estimate is that the cost of allowing dupes is probably much lower than the cost of forbidding them. Finally, our charter does say that we're also supposed to specify how you'd go about archiving feeds, and AllowDuplicateIDs makes this trivial. I looked around and failed to find how we claimed we were going to do that while still forbidding duplicates, but it's possible I missed that. 3. Alternate Paces I didn't want to just revive PaceRepeatIdInDocument, because it used the word version in what I thought was kind of a sloppy way, and because it wasn't current against format-08. I don't like either PaceDuplicateIDWithSource or ...WithSource2, they are complicated and don't really meet PubSub's needs anyhow. So I'm strongly -1 on both of those. Yes, that means that if this Pace fails, we'll allow no duplicates at all. I prefer either dupes OK or no dupes to dupes OK in the following circumstances; cleaner. 4. Details Section 4.1.2 of format-08 says that atom:entry represents an individual entry. The Pace says that if you have dupes, they represent the same entry, which I think is consistent with both the letter and spirit of 4.1.2. The Pace discourages duplicate timestamps without resorting to MUST language, because accidents can happen; this allows software to throw
Re: PaceAllowDuplicateIDs
On 5 May 2005, at 15:55, Graham wrote: On 5 May 2005, at 2:26 pm, Eric Scheid wrote: perhaps we needed atom:modified after all :-( Yes we do, if we want to go down this route. I suggest appending the current time (or for old versions, the last time that version was current) at the source. Sorry I don't understand why we need atom:modified. And what about the use case of a wiki's RecentChanges log? Each entry refers to a specific page, and there may be multiple such entries for each page as it gets rapidly edited ... and wiki folks have found it important to be able to monitor all change events. Each log entry is an entry in itself, with its own id. That seems a far better functional parallel to the basic blog feed. As I explained in my lengthy reply to your lengthy post, I think one should be able to do either. Each way has its advantages and disadvantages. Let the publisher decide which mechanism to use. As with the share price example, the topic of the entry (the company, or the wiki page) is far more analogous to a category that the entry belongs to, than to an its identity. Again let the publisher choose what the identity criterion of his objects are. Some will stick some will not. But it is not up to us to decide for our users. Since it does not cause any interoperability issues, what's the problem? Everyone stop trying to use ids as a category system. I don't think that one would be using ids as a category system. If you go to http://google.com you get todays front page. Tomorrow you get tomorrows front page. What's the problem? Is http://google.com a hidden category system? Henry Story http://bblfish.net/blog/
PaceAlternateLinkWeakening
I have put PaceAlternateLinkWeakening on the wiki, though it was discusses on this list, as it might not have cought the eye of the editors/secretary. http://www.intertwingly.net/wiki/pie/PaceAlternateLinkWeakening I think this is very uncontroversial clarification. Henry Story
Re: PaceAllowDuplicateIDs
On 5 May 2005, at 16:38, Graham wrote: On 5 May 2005, at 3:32 pm, Henry Story wrote: As I explained in my lengthy reply to your lengthy post, I think one should be able to do either. Each way has its advantages and disadvantages. Let the publisher decide which mechanism to use. Well please flag it so that I can provide a consistent user interface to people's whims? What is the problem with the user interface that you have exactly? I have pointed you to BlogEd that keeps a history of all the changes to an entry. Try it out: http://blogs.sun.com/roller/page/bblfish/ Its open source, so you can also copy the code. If you don't want to keep a history of the entries all you need to do is drop all but the latest entry with the same id. There is nothing more to it. Just show the user the last one you came across. Since it does not cause any interoperability issues, what's the problem? I have to come up with a new way to recognise and interpret such feeds where an entry (as defined by its id) isn't an entry but a feed of different entries. No you don't. Just drop the old ones, if you don't care about the history. Really simple. As Tim Bray's text says [[ software MAY choose to display all of them or some subset of them ]] So just drop the older versions. I don't think that one would be using ids as a category system. If you go to http://google.com you get todays front page. Tomorrow you get tomorrows front page. What's the problem? Is http://google.com a hidden category system? Charter: Atom defines a feed format for representing resources such as Weblogs, online journals, Wikis, and similar content yes, and it must also allow the representation of [[ * a complete archive of all entries in a feed ]] This proposal permits this, and it does not harm anyone else. Atom is not a replacement for HTTP. Google.com is a web page, not similar content. It's not relevant here. I don't know where you get the idea that I said atom is a replacement for HTTP. Take a breath perhaps and relax before you answer. Graham
Re: PaceAllowDuplicateIDs
Hi Dave, nice to see you participate here. I understand your points, and I myself thought the way you did for a while. [Oops, I see now that you have retracted your point. Oh well. I had already started writing the following] On 5 May 2005, at 17:27, David M Johnson wrote: I'm -1 on PaceAllowDuplicateIDs Please consider the following points before you vote. Reasons: 1) We're supposed to be standardizing current practice not inventing new things. Current best practice is to have unique IDs and current software (e.g. Javablogs.com) is predicated on this practice. I know, this practice is not followed widely enough, but that is another matter. Atom is standardizing current practice, but it is also adding some features. For example name spaces and ids. The atom charter also requires us to allow archives [[ * a complete archive of all entries in a feed ]] Graham himself thinks that archives are possible, since he supports the use of an archive head element. 2) I think it is *much* more useful to think of an Atom Entry as an event that occurred at a specific time. Typically, an event is the publication of an article or blog entry on the web. For example: event: CNET published article subject: CNET object: article But an event it could also represent other events. event: delivery van delivers package subject: delivery van object: package event: alarm system sends warning subject: alarm system object: warning event: server sends load warning subject: server object: load warning If you think of Atom Entries as events, then it makes sense to consider the Atom Entry ID to be the ID of the event, not the ID of the subject or object of the event. You are right. There are two types of objects that we need to think about: A- the event/state of a resource at a particular time B- the thing that makes these different states the state of the same thing Clearly we need (B) or else all the talk about an entry changing over time (atom:updated) would not make sense. So let us start off, as I did a long time ago, by thinking that the the id of an entry uniquely identifies the event/state of the entry. For every id there can be only one and only one entry/entry representation. That id is that representation. It is, if you wish, the name of a state of something else... and that would be? I think it is clear that one of the roles of the id is to make it possible for an entry to be moved from one web site to another, so that if your blog service provider lets you down, you can still refer to the entry even when you have moved it to a different alternate position. Graham has made such a point quite often. Entries it has often been said can change, but the id remains the same. I think this is clearly the consensus on this list. So the id URI is what identifies the different entry.../entry representations as being representations of the same thing. Events are unique (you can't have more than one version of an event) and can be assigned GUIDs and therefore you cannot have more than one entry with the same ID. yes. But I don't think that this is the consensus on this group. The good thing is that you can achieve the same identification of a state through the combination of the id and the modification time. [here I noticed that you had changed your mind, anyway. I think I had exactly the same thought as you did when I first started thinking about this. ] In the case of earthquake data, each new data report is a new event. event: agency reports earthquake data subject: agency object: earthquake data The ID is the ID of the data reported event not the ID of the earthquake. We don't know what subjects and objects people are going to use in the future, so we can't specify Atom elements or IDs for subjects and objects -- that's what extensions are for. If you want to create a feed to syndicate information about earthquakes, then you introduce an extension for uniquely identifying earthquakes. The same goes for earthquakes. - Dave
Re: PaceAllowDuplicateIDs
On 5 May 2005, at 17:53, Graham wrote: On 5 May 2005, at 4:22 pm, Henry Story wrote: If you don't want to keep a history of the entries all you need to do is drop all but the latest entry with the same id. There is nothing more to it. Just show the user the last one you came across. But, if we follow Eric's model of how a wiki changelog should be defined, I'll be missing entries in the log, because several different entries have the same id. Ergo, the user interface and data model for the new type of feed this proposal permits is very different. If your tool (Is it Shrook2? [1]) only shows people the latest version available to you of an entry, then by showing them only the latest version, Shrook2 will be giving the user what he is expecting. When your news reader currently reads feeds on the internet what does it do with changed entries? Either it keeps the older version around, for the user to browse, or it does not. If your users don't mind you throwing away the older versions of an entry, then they won't mind you throwing away the older versions of the above entries either. There is no difference in the behavior between allowing changed entries across feed documents and changed entries inside a feed document. People who place two entries with the same id inside a feed document should be aware that tools like yours will have the behavior they do, and that this is ok. Other people may be interested in looking at things historically. They will get a historical viewer and be happy with it. I think the current proposal is good exactly because it allows the wiki people to express what they want to express correctly. Namely how their wiki entry is changing over time. This proposal permits this, and it does not harm anyone else. It harms everyone, by allowing a second, unrelated data model in Atom feeds. They may not be posting today, but I assure you, when other aggregator authors get the first user complaints about how Eric's wiki log displays incompletely in their program, they'll forgive Dave Winer everything. Again, has anyone yet complained to you that you have not kept a historical and browse-able track record of how the entries Shrook2 is looking at have changed over time? Clearly they could, as you sometimes let them know that an entry that they already have read has been updated. They could ask you what the changes were, no? How it changed, etc. If your users don't care that much about the history of an entry, then you can dump all but the latest entry. Or you could just keep the last two entries, so that you can show them a diff. Graham HJStory http://bblfish.net/blog/ [1] http://www.fondantfancies.com/apps/shrook/
Re: PaceExplainDuplicateIds
On 1 May 2005, at 18:18, Eric Scheid wrote: On 2/5/05 1:51 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: I would +1 allowing identical IDs if it was required that the entries sharing an ID had different sources. perhaps we need to explain the concept of 'entries' (as resources), as distinct from entrys (as representations), and explain that 'entries' must have unique IDs, and that the atom:id element of any atom:entry ties it back to the 'entry' resource. It would then follow that multiple entry representations which happen to have the same atom:id value are just different representations of the source 'entry', and possibly even different instantiations in time. Exactly. I think this will help dissolve the issue very easily. The way I am currently thinking of this is as follows. The entry/entry xml we find in a atom feed is a time stamped representation of a resource. It is the state of a resource at a particular time. Or perhaps better: it is metadata about the state of a resource at a particular time. If we then think of the entry id as a resource, then we may think of all of these xml representations as representations of that id, where the representations each specify the date and time of their validity. Because the representations contain the date and time of their validity they can be placed in a collection without ambiguity. So there is a little distinction we need to be careful of: an entry.../entry representation is a representation *of* the id resource, but these representations are *about* the state of some other resources at a particular time (most notably the link alternate resource). Henry Story http://bblfish.net/blog/ e.
Re: PaceOptionalSummary
I'll +1 on MAY. On 27 Apr 2005, at 04:29, Robert Sayre wrote: On 4/26/05, Tim Bray [EMAIL PROTECTED] wrote: Paul I are gonna watch a little more debate and then we'll call rough consensus one way or the other, at which point I at least will become crushingly rude to anyone who wants to invest more time in this. Yeah, so now Sam and Graham are off making up requirements to add to the spec. This is over and its a waste of the WG's time. Let me summarize: MUST: Sam SHOULD: Graham, Roger Eh: Bill MAY: Myself, James T, Antone, Eric, Julian, Martin, Aristotle Robert Sayre
call for a vote - was: One reason we have duplicates entries is that we have duplicate feeds...
I don't see where the consensus was by the way. And I never saw any vote on the issue. Like most issues one gets the impression that Atom is run on some pretense democracy. Some people have made up their minds for god knows what reason, and others are just here to follow. The more we chatter on this group the more we lend credence to the notion that there was some consulting done on the issues. But any carefully crafted arguments put in favor of any issue are ignored. No wonder any attempt to be precise about issues gets ignored here, as that may just reveal the corruption behind the scenes. As far as I can remember not one good reason was put forward as to why there should be a restriction of one entry with the same id per feed. In fact I was nearly convinced that the consensus was to drop the restriction. So I call for a real open vote on the issue. Henry Story On 19 Apr 2005, at 10:13, Bill de hÓra wrote: The problem here is, of course, that 4.1.1 of the specification says: atom:feed elements MUST NOT contain atom:entry elements with identical atom:id values. Thus, one of the two entries should not have been written to the feed. Which of the two entries should NOT have been written? Note: There is no good answer here. You might have an attack or you might just have a secondary copied entry that is being inserted. In any case, there isn't enough info to know which to accept and which to reject. So... I believe that the prohibition against multiple entries with identical IDs should be relaxed to say: [...] We discussed this and the consensus said that the prohibition should stand (iirc I was pro multiple IDs in a feed). As it happens I think error handling will be contextual in reality - I really doubt client aggregators will drop an entire planet* Atom feed because two entries have the same ID.
Re: call for a vote - was: One reason we have duplicates entries is that we have duplicate feeds...
On 19 Apr 2005, at 18:27, Bill de hÓra wrote: Henry Story wrote: So I call for a real open vote on the issue. You don't need to call for a vote, just ask the chairs/editors who keep track of such matters, about the particular specification. Well we need some objective way to tell what the consensus is. Going from your or my recollection does not seem to help, since by reading this list we end up with completely different points of view on where the consensus is. If you can point out to me my recollection of the consensus on that issue is incorrect, then do so. Beyond that, dark mutterings about corruption carry little weight with me. We never had a vote so what can I point to? I could point to some people putting forward some arguments and then others putting others forward. The reason we have arguments is in order to convince someone, so how do I know what the consensus is at the end of the argument? People may have changed their position throughout the argument, especially if there are highly intelligent people putting very good reasons forward. On the issue of not allowing more than one entry per feed with the same id, I heard some very bizaare reasons, such as there being a major problem with web architecture that nobody has heard of. But is this a reason that has convinced anyone? cheers Bill
Re: call for a vote - was: One reason we have duplicates entries is that we have duplicate feeds...
Ok. I am sorry. I thought I had made a really good case for a simple argument to allow multiple entries with the same id in a feed, and thought it had in fact made it into the spec. I then discovered that it still had not. I cleazrly just have no idea how one goes around convincing this group of anything, so I'd better not participate anymore. On 19 Apr 2005, at 19:20, Paul Hoffman wrote: At 6:12 PM +0200 4/19/05, Henry Story wrote: I don't see where the consensus was by the way. Correct. There was no consensus to remove the current wording. And I never saw any vote on the issue. Correct: there was no voting, there was a consensus call. I'm not sure how you could have missed it: PaceRepeatIdInDocument was discussed *heavily* in the past few months. The conclusion was: PaceRepeatIdInDocument Lots of discussion, more -1's than +1's. DISPOSITION: No consensus, close it. But now we have a problem, in that this removed ambiguity in one direction, just closing it leaves the ambiguity. So the only logical conclusion is that the WG is directing the editors to put language in that explicitly forbids entries with duplicate atom:id in an atom:feed. Yes. I remember the above point very well. And I was very surprised by it. After all here is a decision being made to close a pace and take a decision with regard to it that is not explicitly stated in that Pace without then putting it back forward to the group. I in fact did question that decision and this went on in a long thread PaceRepeatIdInDocumentSolution and so on. I suppose the result of that argument was not clear either. Again I suppose I just don't understand how to make an argument that can convince the group. Henry Story
Re: call for a vote - was: One reason we have duplicates entries is that we have duplicate feeds...
Just to end on a positive note, I'll +1 this suggestion by Graham. Henry On 19 Apr 2005, at 18:30, Graham wrote: I'm in favour of allowing duplicate ids when the source-id is different to simplify creating merged feeds, which would allow the client to figure out what to do. Under any other circumstance, definitely not. Graham
Re: I don't get it, perhaps you could include an expanded explanation in a textual message, now that our machine protocol has broken down.
My mother does this all the time. :-) On 8 Apr 2005, at 14:23, Bill de hÓra wrote: :) Only that it's common enough (in my part of the world anyway) to send short messages in subject lines that end with 'eom'. The point is that people do communicate solely through subject lines in email. I think that probably lends weight to your position. cheers Bill
Re: PaceAlternateLinkWeakening
Here is a nice small surgical change. I am not sure if I have convinced Thomas Broyer with the diagrams I put online, but I am still very happy with the following replacement, after having carefully looked at the criticisms. Proposal A -- replace [[ 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. ]] 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. ]]
next, previous
Are the next and previous links that we thought may be attachable to the feed really too controversial to get into the final atom spec? They would be really useful to archive feeds. Henry Story
Re: PaceAlternateLinkWeakening - was Managing entries/entry state
Let me skip right to the core of your answer. On 3 Apr 2005, at 00:06, Thomas Broyer wrote: What about: [[ The value alternate signifies that the IRI in the value of the href attribute identifies a resource whose representations are an alternate version of the resource described by the containing element. ]] The question is here: what is the resource described by the containing element referring to? As I argued in a previous post to this thread [1] my belief is that this is the resource named by the id of the entry. I did not make that aspect of my thinking visible in the graph attached to my previous mail [2] so I will now, by adding the representation relations (named repres) in the following graph: inline: Atom-related.jpg The entry... in green and in yellow are representation of the urn:uuid:1225... resource, just as the yellow html... and xhtml... representations are representation of the else.html resource, and the green html... and xhtml... representation are of the displaced.html resource. Now if I look at your definition above you are relating two resource the same way the current spec does. Say we had an alternate link on the green entry..., then your definition would be relating the urn:uuid:1225... resource to the displaced.html resource. But what I don't understand is that you are saying the representations of displaced.html namely the green html and xhml representations are alternate versions of urn:uuid:1225. How can representations be alternate versions of a resource? Perhaps you mean that they are alternate versions of the representations described by the urn:uuid:1225...? [1] http://www.imc.org/atom-syntax/mail-archive/msg13940.html [2] see: http://www.imc.org/atom-syntax/mail-archive/msg13959.html Henry Story wrote: On 1 Apr 2005, at 19:52, Thomas Broyer wrote: Taking back Eric's example: entry ... link rel=http://example.org/rels#next; href=http://example.net/somethingelse.atom; / ... /entry My interpretation is that ...somethingelse.atom is the next (entry or whatever is defined by the @rel value herein) from the point of view of the entry containing the link element. ok. ...somethingelse.atom would be the next resource. Though I think the next link was meant for feeds, and has been moved over to the API document. This is not the same next relationship... yes. But it ends up being taken that way. So in the end things get a little confusing. So it is a little unfortunate to be basing your argument on an example that is not in the spec, and that if it were would be attached to the feed. Well, feeds also carry link elements with a possible alternate value for their rel attribute... If you replace the @rel with @rel=alternate, then ...somethingelse.atom is an alternate representation of me (me being the entry carrying the link element). no. ...omething.else.atom is a resource, not a representation [1]. So what you mean to say is that ...somethingelse.atom is an alternate resource of me. But that won't do since me is a representation. Hence what we have to say is that me is an alternate representation of the ...somethingelse.atom resource. Ok, I finally understand what you mean... Actually, the problem is applying alternate version to resource rather than representation of a resource. [sniped and copied to head of mail] I really don't see the problem entry.../entry ---alternate--- ..else.html think of it as a short hand for entry.../entry ---alternate-representation-of--- ..else.html But the former one says (fmpov) something like ...else.html is an alternate of entry while the latter says entry is an alternate (representation) of ...else.html. You are switching the directions of the meanings (ok, without switching the directions of the arrow... that's something like active/passive forms in grammar) Perhaps we should first get to agree on the arrows we want, and then try to work out how the english is going to express the arrows we want. I think we both agree on the direction of the arrows. Here we are! As I said above this is not a causal relationship. We are not saying that the entry.../entry representation is known by the hrefed resource, that it can produce it, or anything like that. We are just saying that it is an alternative representation (alternative is happily quite vague) of the remote resource. yes whichever is the primary representation... Well, in a few words: they are alternate representations of the same thing. They meaning what? ...else.html and entry.../entry are not both representations only the second one is. The problem with the web-arch language is that once you print a web page (a representation of a resource), it (the printed sheets) is not the same resource any more (if I understand correctly). Though the still are resources/representations/call-how-you-want of the same thing. what you mean is that ...else.html has many representations. Some of these are html ones
Re: PaceAlternateLinkWeakening - was Managing entries/entry state
On 3 Apr 2005, at 23:02, Thomas Broyer wrote: Henry Story wrote: Perhaps you mean that they are alternate versions of the representations described by the urn:uuid:1225...? That's it! (I think...) Now that we agree, I let you use the web-arch to describe it. Ok. So let us try the slightly clumsy (to be improved later) definition What about: [[ The value alternate signifies that the IRI in the value of the href attribute identifies a resource whose representations are an alternate version of the representation described by the resource described by the containing element. ]] inline: Atom-related.jpg and let us look at the application of this definition to the example of our graph above. Here you see that the urn:uuid:1225... does not have 1 representation, but two representations: the yellow and the green entry... representations. One of these representations (the yellow, older one) had a link to else.html, while the other (the greener, newer one) had a link to displaced.html. So according to your definition the green tom2:alternate arrow (the one that arises from the information in the green entry) says is that these two yellow and green entry representations are alternates of the green xhtml... and html... representations. But that is not quite what we want to say, since that would make the older yellow entry... representation an alternative of the newer green html and xhtml representations. These might have changed only a little during the displacement, but they may also have changed a lot more. This just does not seem quite right. Now I can hear you think (amazing powers that I have :-) that what you really mean is that the green entry representation alone (not the older yellow one) is an alternate version of the representation of the displaced.html resource. But if you mean to say that, then why bring urn:uuid:1225... the id of the entry into the picture at all? Let us just cut it out, since the link construct can indexically refer to the representation in which it is located. [[ The value alternate signifies that the IRI in the value of the href attribute identifies a resource whose representations are an alternate version of the containing element. ]] Now I think we have another way of saying what I meant by the A:alternate relation. Which of the phrasings is better, the one above or [[ 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. ]] is now a matter of which one is clearer. But I think we are describing the same relation. Henry Story
Re: PaceAlternateLinkWeakening - was Managing entries/entry state
On 1 Apr 2005, at 19:52, Thomas Broyer wrote: Henry Story wrote: On 1 Apr 2005, at 14:53, Eric Scheid wrote: Prior art in other specs says the relationship is from where the link is found, and to the thing at @href. I think we are agreeing here. The link is from the representation entry/entry to the resource identified by the href. That is what proposal A says, I think. Not for me... Taking back Eric's example: entry ... link rel=http://example.org/rels#next; href=http://example.net/somethingelse.atom; / ... /entry My interpretation is that ...somethingelse.atom is the next (entry or whatever is defined by the @rel value herein) from the point of view of the entry containing the link element. ok. ...somethingelse.atom would be the next resource. Though I think the next link was meant for feeds, and has been moved over to the API document. So it is a little unfortunate to be basing your argument on an example that is not in the spec, and that if it were would be attached to the feed. If you replace the @rel with @rel=alternate, then ...somethingelse.atom is an alternate representation of me (me being the entry carrying the link element). no. ...omething.else.atom is a resource, not a representation [1]. So what you mean to say is that ...somethingelse.atom is an alternate resource of me. But that won't do since me is a representation. Hence what we have to say is that me is an alternate representation of the ...somethingelse.atom resource. Now you example is also a little confusing because the type of object that should be at the end of an alternate link, would usually not be an atom document, but an html document. So let us for the sake of clarity replace ...somethingelse.atom by ...somethingelse.html at the same time as we move from next to alternate If you want to say that the entry is an alternate representation of the thing at @href, then (re)introduce the rev attribute: @rev=alternate, meaning I am an alternate representation of the thing at @href where I is the entry carrying the link element. I really don't see the problem entry.../entry ---alternate--- ..else.html think of it as a short hand for entry.../entry ---alternate-representation-of--- ..else.html You don't have to switch the directions of the arrows for this to be correct. As you see it is a relation from representation to resource. Perhaps you are thinking alternate-representation-of is some causal relationship and so the arrow points from the resource to the entry representation. Since it is easy to think of as the resources (in http land at least) as causing their representation. But there clearly need be no such causal relation at all between the resource at ..else.html and the entry.../entry representation. ..else.html may be a resource that only produces html representation of it. It is none the less true that the entry may be an alternative representation of that resource. The relationship is logical not causal. One could also think of the @rel=alternate as a bi-di relation: we (the entry carrying the link element and the thing at @href) are alternate representations of the same thing, without telling which is the primary representation (maybe neither of both is, maybe the primary representation does not have any IRI). This means that @rel=alternate has the same meaning as @rev=alternate. (Again I think here you are mislead by thinking of the realtion as a causal one.) One can't quite think of it as a bi-directional relationship, since the relation is asymmetric. entry.../entry ---alternate-representation-of--- ..else.html works, but ..else.html ---alternate-representation-of--- entry.../entry does not. ..else.html is not a representation, it is a resource. [1] Well, finally, I'll go for the last... As we are looking at the relation from the point of view of the entry carrying the link element, it is clear that the thing at @href is an alternate representation of the entry that we know of, yes but it is not defined that the primary representation might be the entry nor that the thing at @href knows of the entry as an alternate representation of itself, Here we are! As I said above this is not a causal relationship. We are not saying that the entry.../entry representation is known by the hrefed resource, that it can produce it, or anything like that. We are just saying that it is an alternative representation (alternative is happily quite vague) of the remote resource. whichever is the primary representation... Well, in a few words: they are alternate representations of the same thing. They meaning what? ...else.html and entry.../entry are not both representations only the second one is. what you mean is that ...else.html has many representations. Some of these are html ones that it produces, others are atom ones that are produced by others. We have something like this ...else.html ---representation--- htmlbody.../body/html
Re: PaceAlternateLinkWeakening - was Managing entries/entry state
On 2 Apr 2005, at 14:16, Eric Scheid wrote: On 2/4/05 8:15 PM, Henry Story [EMAIL PROTECTED] wrote: no. ...omething.else.atom is a resource, not a representation [1]. So what you mean to say is that ...somethingelse.atom is an alternate resource of me. Firstly, why is html.../html a representation, while entry .../entry not a representation? I don't understand. Are you asking me? I am asserting that html../html and entry.../entry are both representations. I have put all representations in rectangles in the attached diagram of my previous email, just to make this point. Secondly ... alternate resource ... wha? Argh. I was trying to show what was wrong with Thomas' argument. That is why that does not make sense. If you read on you will see that I criticize his position for that reason. A resource is an abstract thing, reified by representations, right? Something along those lines yes. Henry Story
Re: PaceAlternateLinkWeakening - was Managing entries/entry state
On 1 Apr 2005, at 01:38, Eric Scheid wrote: On 1/4/05 9:10 AM, Henry Story [EMAIL PROTECTED] 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? Yes I thought it made the text easier to read. I did not realize anyone cared. 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) Good, but now you are reverting back to the previous relation type. Keep in mind the question: what are we relating to what? My answer is that we are relating a resource to a representation. Your phrasing, as the one in the spec, is relating two resources, which I argued is too strong. I think I can get the direction back and preserving the weakening of the relationship which is the core of the proposal: Proposal replace [[ 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. ]] with: [[ The value alternate signifies that the IRI in the value of the href attribute identifies a resource for which the containing element is an alternative representation. ]] PS. grammarians might want to tell me of it is of which or for which. e.
PaceAlternateLinkWeakening - was Managing entries/entry state
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 [[ 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. ]] with: [[ The value alternate signifies that the containing element is an alternative representation of the IRI in the value of the href attribute. ]] On 30 Mar 2005, at 14:34, Henry Story wrote: 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: On 20 Feb 2005, at 13:25, Bill de hÓra wrote: Graham, Eric, 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 [1]. I would like to be a little more specific now. If I take the following entry from the format 06 spec entry titleAtom-Powered Robots Run Amok/title link href=http://example.org/2003/12/13/atom03/ idurn:uuid:1225c695-cfb8-4ebb--80da344efa6a/id updated2003-12-13T18:30:02Z/updated /entry Then we can say that the above Entry is a representation of the urn:uuid:1225c695-cfb8-4ebb--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--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--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--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--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
Re: PaceAlternateLinkWeakening - was Managing entries/entry state
On 1 Apr 2005, at 00:34, Mark Nottingham wrote: On Mar 31, 2005, at 10:07 AM, Henry Story wrote: The value alternate signifies that the containing element is an alternative representation of the IRI in the value of the href attribute. ...an alternate representation of the resource identified by the IRI in the value...? yes correct. Thanks for pointing this out. Proposal replace [[ 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. ]] 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. ]] -- Mark Nottingham http://www.mnot.net/
Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]
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: On 20 Feb 2005, at 13:25, Bill de hÓra wrote: Graham, Eric, 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 [1]. I would like to be a little more specific now. If I take the following entry from the format 06 spec entry titleAtom-Powered Robots Run Amok/title link href=http://example.org/2003/12/13/atom03/ idurn:uuid:1225c695-cfb8-4ebb--80da344efa6a/id updated2003-12-13T18:30:02Z/updated /entry Then we can say that the above Entry is a representation of the urn:uuid:1225c695-cfb8-4ebb--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--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--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--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--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
atom link analysis - was: link confusion?
I was trying to interpret the atom:link element [1] If I try to look at the spec in a simple relational way (what is being related to what?) then, given the following example atom xml extract, entry ... link href=http://bblfish.net/blog/page5.html#42; type=text/html hreflang=en length=450 title=The html entry rel=related/ /entry One may think of representing this with the following N3 [ a :Entry; :link [ :href http://bblfish.net/blog/page5.html#42; :type text/html; :lang en; :length 450; :l_title The html entry; # see note [2] :rel:alternative ] ]. The problem to my mind is that the above interpretation of the xml is confusing relations that apply to the link (:rel, :l_title) and relations that apply to the object of the link (:type, :lang, :length). Hence I prefer the following @prefix arch: http://sw.nokia.com/WebArch-1/ @prefix owl: http://www.w3.org/2002/07/owl# [ a :Entry; :link [ :href [ owl:sameAs http://bblfish.net/blog/page5.html#42; arch:representation [ :type text/html; # note [3] :lang en; :length 450 ] ] :l_title The html entry; # see note [2] :rel:alternative ] ]. That seems quite good. Now the interesting thing is that from the above it would seem that one should be able to deduce the following: [ a :Entry; :alternative [ owl:sameAs http://bblfish.net/blog/page5.html#42; arch:representation [ :type text/html; # note [3] :lang en; :length 450 ] ] ]. Ie. the link object is not really an object, but as its name suggests is really a relation. This would not be such a problem except for the fact that we have now lost the title information that was placed on the link object. So perhaps what we have is that the link object is an anonymous rdfs:SubPropertyOf the object of its :rel relation (in our example :alternative) which has a special title attribute. That would allow us to make the above deduction I think. So if variable relations were allowed (they may be in N3, I am not sure), one could write [ a :Entry; _:link [ owl:sameAs http://bblfish.net/blog/page5.html#42; arch:representation [ :type text/html; # note [3] :lang en; :length 450 ] ] ]. _:link :rel :alternative; :l_title The html entry. where :rel is itself a rdfs:SubPropertyOf rdfs:SubProperty. This may make the atom link relation clearer to some :-) Henry Story [1] http://www.atompub.org/2005/03/12/draft-ietf-atompub-format-06.html [2] the title attribute of the link is called l_title to avoid confusing it with the title element of the entry [3] I am surprised the web arch ontology does not have the vocabulary for :type, :lang and :length that atom has. On 25 Mar 2005, at 21:32, Henry Story wrote: On 25 Mar 2005, at 17:36, Henry Story wrote: given the following example xml, entry ... link href=http://bblfish.net/blog/page5.html#42; type=text/html hreflang=en length=450 title=The html entry rel=related/ /entry [snip] So a better interpretation of the initial xml would be the following _e1--is-a- Entry |--link- _link |--to_r--is-a- Representation | |--href-- http://bblfish.net/blog/page5.html#42 | |--type-- text/html | |--lang-- en | |-length- 450 |-title-- The html entry |--rel--- related Another interpretation of the original xml which would take into account the fact that a link MUST have an href element would be: _e1--is-a- Entry |--link- _link |--href--http://bblfish.net/blog/page5.html#42 | |--representation--_r | |--type-- text/html | |--lang-- en | |-length- 450 |-title-- The html entry |--rel--- related which is saying that a link relates an entry and a resource, and that sometimes it is appropriate to give extra information about representations of that resource. And so more it would perhaps be clearer for the xml to be stated like this entry ... link title=The html Entry rel=related href=http://bblfish.net/blog/page5.html#42; representation type=text/html
Re: Why is alternate link a MUST?
+1 I think it makes a lot less sense for a feed than it does for an entry. Henry On 23 Mar 2005, at 14:19, Brett Lindsley wrote: I know this discussion has occured before, but I would like to revisit the question of why an atom:feed MUST contain at least one atom:link element with a relation of alternate (-06 4.1.1). The defintition of the alternate representation is it identifes an alternate version of the resource (Sec 4.2.9.2). However, is it realistic to believe that *every* feed has an alternate version? This becomes even more confusing if one considers the possibility of branching out using service.feed to filtered, searched or aggregated views. One would expect the link to have an alternate representation of the filtered, searched or aggregated feed as well. I have seen some examples where a home page was used for all of the alternate representations. Is a home page really an alternate representation? Putting a home page in feeds that are filtered or aggregated versions is also misleading because the home page would most likely not be an alternate representation of the filtered/aggregated feed. I can also think of situations where a server hosts feeds that do not have an alternate representation nor have a home page. In this case, why have a required link that serves no useful purpose. Why isn't this requirement a may instead of a must? I can see having a link with rel=alternate if indeed a alternate version does exist. It does not make sense to put in some something misleading if an alternate does not exist. Brett Lindsley, Motorola Labs
Re: link questions
Thanks, that helps a lot. Perhaps what is missing are use cases. Henry On 29 Mar 2005, at 03:34, John Panzer wrote: Henry Story wrote on 3/28/2005, 4:12 PM: - I must have missed the arguments about self. But the documentation does not really help me understand what I would want to use that link for. (Perhaps this is to point to a translated version of the resource for example?) Is this the use case? I've clicked on an Atom feed link and the data (but not the originating URI) have been passed to a handler of MIME type application/atom+xml. I like what I see and want to subscribe to the feed... but there's no way to figure out what URI to subscribe to without the self link inside the data. -- John Panzer Sr. Technical Manager, AOL http://journals.aol.com/panzerjohn/abstractioneer
copyright
Hi, I just looked at Lawrence Lessig's presentation to the Library of Congress [1], and noticed his blog that shows Yahoo! search launching a creative commons search engine [2]. Clearly it would be very helpful if there were a machine readable way to set copyright policy on entries. Any thoughts on that? Henry Story [1] http://bblfish.net/blog/page5.html#43 [2] http://www.lessig.org/blog/archives/002790.shtml
Re: Person identity
I like this - even though I disagree with the constraints - as it follows nicely on the parallel I developed in the Madonna example [1] between personal identity and entry identity. Clearly if the same atom:id were to be used then we are identifying the id that appears in an entry and the id that would appear in the Person construct. But I have argued that the relation between an entry and the relation of atom:id is a functional one, ie: - that an entry can only have one atom:id relation to an id construct - that an id construct can have many 1/atom:id (the inverse relation) relations to Entry constructs. This makes sense: entries can change over time and we wish to be able to capture this fact logically. Entries as they appear in an Atom feed are time-stamped objects. Each of these time stamped objects with the same id is a different version of the same timeless entry. This could be equally true of the Person construct and its relation to the atom:id that identifies it. But in that case we have to allow, as with entries, that things can change. So that one could have a Person construct with the same id and yet different properties (people change their e-mail address over time, live in different places, etc) In the atom case this is at present not very useful, since there are not many other properties, and since we do not time stamp, as we do with entries, the Person constructs. But this would have to be a consequence of using the same atom:id tag as we use in the entry. And so consequently the proposed restriction (c) is incompatible with the atom:id name. It is important to notice that there are two relations (at least) that relate temporally changing objects like Persons and Entries to their ids: (1) a relation that relates a temporal part of the person to the id (2) a relation that relates the unchanging mereological sum [2] of these parts to the id. (2) may be an inverse functional relation, ie: - there is only one such object related to the id construct in such a way. - there may be more than one id that identifies the same person. (2) is closer to the relation the foaf [3] folks have used to identify the Person and agent objects. And (2) is also closer to the intent of your restriction (c). Given the popularity of foaf, people may be inclined to associate the atom:Person construct with the foaf:Person. Note also that these are two different but non exclusive relations. The unchanging Person that is Tim Bray, the 4 dimensional object that exists from a certain conception moment to a certain death moment (assuming he is mortal), has many temporal parts, one or more of which may be reading this sentence. The 4 dimensional unchanging object has a relation to Tim Bray's social security number. But so of course do the temporal parts mentioned above. If we have two different descriptions of this 4 dimensional object then we can merge these descriptions and still say something true. This is not true of any of the temporal parts. One of the temporal parts reading the above sentence may be scratching his head in Vancouver and the other may be flying over California, and it would be wrong to merge the two and say that they were both in Vancouver and over California. So in conclusion either: - you have to drop (c) - or you have to give the relation a name other than atom:id Henry Story [1] http://www.imc.org/atom-syntax/mail-archive/msg13618.html [2] http://plato.stanford.edu/entries/mereology/ [3] http://xmlns.com/foaf/0.1/ On 18 Mar 2005, at 16:23, Thomas Broyer wrote: I propose adding an optional atom:id element to the Person construct content model, with the following rules (to be reworded before adding into the spec): a) There MUST NOT exists more than one contributor with the same id in an entry of feed b) There MUST NOT exists a contributor with the same id as the author in an entry or feed c) Each Person construct (in a feed) refering to the same person/organization/etc. SHOULD be identical (same value for atom:name, atom:id, atom:email and atom:uri; and if, e.g., atom:email is given, it SHOULD appear in each of these Person construct) d) Person constructs refering to different persons/organizations/etc. SHOULD use different atom:name values all over the feed/entry e) atom:id SHOULD be provided if known but MUST NOT be generated automatically just to provide one or be given without the actual person/organization/etc. aknowledgement (as it is a _globally_ unique identifier).
Re: draft-ietf-atompub-format-06
What's the problem exactly? The spec looks quite nice to me on the whole. ((Perfection would come with an OWL semantics as shown by RSS1.1, but otherwise it looks ok.)) Henry Story On 16 Mar 2005, at 16:17, Graham wrote: On 16 Mar 2005, at 1:03 pm, Robert Sayre wrote: PaceHeadless. The chairs agree that both reads are reasonable, and are ok with this divergence. The working group aren't. Revert PaceHeadless immediately. Graham
Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]
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/
Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]
On 23 Feb 2005, at 08:53, Henry Story wrote: On 23 Feb 2005, at 00:18, Bill de hÓra wrote: Sorry that should have been Paul Hoffman wrote: My read of the mailing list is that people are simply looking at the model described in the document differently. Some folks actively want the model the way the document currently reads, other actively want the model to be different, and most don't care about the differences between those two. That is a very diplomatic way of putting things :-) since we don't know what you mean by the way the document currently reads. There was an attempt to resolve the ambiguity of how many times an entry with the same id can appear in a feed document. The resolution of this ambiguity in favor of one model over the other at such a late stage in the game can seem like an attempt by some to impose their reading of the spec. I would be in favor of not resolving the ambiguity but of highlighting it with text such as [ whether more than one entry with the same id can appear in a feed document has not yet been resolved ] Bill de hÓra then responded: [[ -1. That is of no little value to a user of the spec. Also, do read what I said earlier in this thread - I'm not looking to resolve ambiguity, I'm looking to specify what's going to be ambiguous. ]] To which I reply: This is getting to be a very subtle distinction, and I am having trouble following. I am not trying to resolve ambiguity. The text above is looking to point out in the text what is ambiguous. The hope is that questions such as the ones you are asking in this thread, and work on the protocol, will help clarify the ambiguity and perhaps resolve it to everyone's satisfaction. This would have the virtue of not taking sides in the debate and of not forcing one reading by default. We can then move onto the protocol issue, which I think will force the clarification of what an Entry is, and thereby the arguments as to why one reading or the other should be preferred. Henry Story
Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]
I like the way you put the question below. It is indeed very clear. But it does not seem incompatible with us adding some text now in the spec that acknowledges that we have not yet answered the questions you pose. I would surround this text with square brackets [] just as we have done with other parts of the spec that are not finished. I certainly prefer this to text being added that suddenly cuts the issues arbitrarily. If I follow your reasoning correctly whatever way one cuts this, one is left with a problem. These problems had not been acknowledged clearly before, so there is no guarantee that this group has in fact agreed on anything with respect to this. The problem therefore does either need to be resolved or it has to be acknowledged. I propose we acknowledge the problem in the just-about-to-come-out revision of the spec with language with an effect similar to the following: [ whether more than one entry with the same id can appear in a feed document has not yet been resolved ] rather than go the way Tim Bray was thinking of going, namely: PaceRepeatIdInDocument Lots of discussion, more -1's than +1's. DISPOSITION: No consensus, close it. But now we have a problem, in that this removed ambiguity in one direction, just closing it leaves the ambiguity. So the only logical conclusion is that the WG is directing the editors to put language in that explicitly forbids entries with duplicate atom:id in an atom:feed. I would like to answer your questions below, but I would rather wait to see where the whole new version of the spec has put us before embarking on the debate. I gather it should be ready any time now. Henry Story On 23 Feb 2005, at 12:10, Bill de hÓra wrote: Henry Story wrote: Bill de hÓra then responded: [[ -1. That is of no little value to a user of the spec. Also, do read what I said earlier in this thread - I'm not looking to resolve ambiguity, I'm looking to specify what's going to be ambiguous. ]] To which I reply: This is getting to be a very subtle distinction, and I am having trouble following. If you allow multiple entries with the same id in a feed, there's no straightforward way to determine whether the feed provider has defective id distribution. All you do is say these entries represent states of the same thing. If you don't allow multiple entries with the same id in a feed, then feeds become a special aggregation case since you almost certainly want to allow multiple entries with the same id across feeds. This has to do with webarch because the use case for multiple representations (entries) carried inside other representation (feeds) and from multiple authorities aren't covered by it, and bring up such issues as the above, eg, I have no idea whether Atom/RSS represents a new layer above or an extension to, current app protocols. Aside from overall architecture I sepculate that can be expected to have implications for trust, caching, security and design of implementations. So far we've only really talked about the effect on client aggregators in presenting entries to users. * What's subtle about that? :) cheers Bill * This is the point where I start to see where Rob Sayre is coming from with WebDAV.
Re: PaceRepeatIdInDocument solution
On 20 Feb 2005, at 17:10, Graham wrote: On 20 Feb 2005, at 4:07 am, Bob Wyman wrote: PubSub regularly produces feeds with multiple instances of the same atom:id. Which part of universally unique didn't you understand? Ok, I see so you interpret the universally unique in [[ An Identity construct is an element whose content conveys a permanent, universally unique identifier for the construct's parent. Its content MUST be a URI, as defined by [RFC3986]. Note that the definition of URI excludes relative references. ]] to mean that there can only be one entry in a feed with the same id, and presumably across all feeds, or else why use the word universally and not feedally? Why could we not then allow another id construct, call it entryId that would be what all entries that are just editorial changes of one another have in common? This would be something like: feed ... entry idtag:bblfish.net/entry1/version1/id entryidtag:bblfish.net/entry1//entryid titleAtom Robots Run Amok/title ... /entry entry idtag:bblfish.net/entry1/version2/id entryidtag:bblfish.net/entry1//entryid titleAtom-Powered Robots Run Amok/title ... /entry /feed As you can see in the above feed there are no two entries with the same id. Yet there are two entries with the same entryid. Would the above be an ok feed for you, or are there some other reasons why a entryid node would be illegal? It is particularly important to avoid prohibiting this benign practice since it is so important to generators of aggregated feeds. Aggregated feed generators are supposed to maintain atom:id unchanged when they copy entries into an aggregate feed. This is a fair point. I concede that multiple versions of entries with the same id is acceptable if and only if they have different feed ids in their head-in-entry, since essentially then they aren't in the same feed. So should we replace universally unique above with unique in a feed then? Graham
Re: PaceRepeatIdInDocument solution
I think I can prove that the two versions are perfectly compatible and orthogonal. I can prove that logically there is no inconsistency, and some empirical backing that this is feasible. But I am not alone. Bob Wyman I believe has a lot more empirical support. You on the other hand, as usual I notice, have absolutely no argument to defend your case. Henry Story On 18 Feb 2005, at 23:55, Graham wrote: Allowing more than one version of the same entry in a syndication feed is unacceptable in itself, which is fundamentally incompatible with archive feeds, no matter what the conceptual definition of id is. Graham
Re: PaceRepeatIdInDocument solution
On 18 Feb 2005, at 23:55, Graham wrote: Allowing more than one version of the same entry in a syndication feed is unacceptable in itself, which is fundamentally incompatible with archive feeds, no matter what the conceptual definition of id is. Graham Let me make my point even clearer. If something is fundamentally incompatible, then it should be *dead-easy* to prove or reveal this incompatibility. So develop your thought a little, and you can only come out the winner. Henry
Re: PaceRepeatIdInDocument solution
On 19 Feb 2005, at 16:46, Graham wrote: On 19 Feb 2005, at 11:23 am, Henry Story wrote: Let me make my point even clearer. If something is fundamentally incompatible, then it should be *dead-easy* to prove or reveal this incompatibility. i) Syndication documents shouldn't ever contain multiple versions of the same entry*. ii) Archive documents apparently need to be able to contain multiple versions of the same entry. * for the simple reason that it makes them an order of magnitude harder to process and display correctly (and often impossible to display correctly, since it won't always be clear which is the latest version). I don't accept that it makes it an order of magnitude harder to process these documents, or if it is an order of magnitude harder, its an order of magnitude larger than an infinitesimal amount, which is still an infinitesimal amount. I am writing such a tool, so I think I have some grasp on the subject. But accepting for the sake of argument that you are right, you need compare the difficulty of writing a feed reader with the difficulty of writing a feed itself. Not allowing duplicate versions of an entry in a feed just pushes the complexity of writing the feed from the feed reader to the feed writer: now the feed writer has to contain the logic to make sure than no duplicates appear in the feed. Instead of the feed writer just being able to paste the new entry to the end of the feed, it has to parse the whole feed document and make sure it contains no duplicates. Since I can see very good reasons to make life easier for the feed writer, in the same way as one has tried to keep html simple for the common html writer, I think your argument may in fact turn out to be a good supporting argument for allowing multiple versions of an entry in the same feed document. Your wittering on about conceptual models doesn't make you better than us. I never pretended it does make me better. I have been exploring tools such as rdf, as I believe that they can bring a lot of clarity to debates such as this one. Just as engineers don't hesitate to use mathematics to help them in their tasks, so I think using logical analysis should help us here. I hope that as I understand these tools better I will be able to explain the insights these disciplines bring in plainer english. In the mean time I have a lot of respect for Tim Berners Lee, and I try my best to understand the direction he is going in, the tools he is developing and the insights these lead to. Henry Story http://bblfish.net/ Graham
PaceRepeatIdInDocument solution
The PaceRepeatIdInDocument tries to set the constraints in the Identity construct whereas the constraint should have gone on the individual elements. Instead I would replace the following in the spec: 4.5 The atom:id Element The atom:id element is an Identity construct that conveys a permanent, universally unique identifier for an entry or feed. with 4.5 The atom:versionId Element The atom:versionId element is an Identity construct that conveys a permanent, universally unique identifier for an entry or feed. There can only be one entry per feed document with the same id. 4.6 The atom:entryId Element The atom:entryId element is an Identity construct that conveys a permanent, universally unique identifier for an entry or feed. There can be more than one entry per feed document with the same id. Note: atom:versionId is the what I have called elsewhere the equivalence id relation atom:entryId is what I have called the functional id relation The above will allow the feed format to also be used as an archive format if needed. It clearly distinguishes the two types of ids that were hidden in the ambiguous text that PaceRepeatIdInDocument tried to disambiguate one way and others tried to disambiguate the other way. As such it correctly resolves an ambiguity by allowing both options. Henry Story Ps. text above written quickly cause I have to go do some exercise.
Re: PaceRepeatIdInDocument solution
I was not able to go and do the exercise I wanted to do, so here is a more carefully worded version The id construct in atom is ambiguous between two meanings. Since the two meanings are orthogonal and not incompatible when properly distinguished, the best solution is to distinguish them and allow both. I would replace the following text in the spec: 4.5 The atom:id Element The atom:id element is an Identity construct that conveys a permanent, universally unique identifier for an entry or feed. with 4.5 The atom:versionId Element The atom:versionId element is an Identity construct that conveys a permanent, universally unique identifier for an entry or feed version. There can only be one entry with the same versionId per feed document. There can be only one feed document with the same versionId. 4.6 The atom:id Element The atom:entryId element is an Identity construct that conveys a permanent, universally unique identifier for an entry or feed. There can be more than one entry per feed document with the same id. And there can be multiple feed documents with the same id. Note: atom:versionId is what I have called elsewhere the equivalence id relation atom:entryId is what I have called the functional id relation The above will allow the feed format to also be used as an archive format if needed. It clearly distinguishes the two types of ids that were hidden in the ambiguous text that PaceRepeatIdInDocument tried to disambiguate one way and other Paces tried to disambiguate the other way. As such it correctly resolves an ambiguity by allowing both options. Henry Story Ps. text above written quickly cause I have to go do some exercise.
PaceRepeatIdInDocument was: Consensus call on last round of Paces
I should emphasize that there are in fact deeper problems with trying to limit the number of entries with the same id to one per document. The notion of an id that this entails, which in another mail I have called the equivalence relation id, in fact makes the whole notion of feeds chained by next and previous links inconsistent. This will create a really deep flaw in Atom. Therefore I think the conclusion that the group has decided not only against PaceRepeatIdInDocument but furthermore for a restriction is a understandable but very dangerous conclusion to come to. sincerely, Henry Story On 15 Feb 2005, at 20:38, Henry Story wrote: On 15 Feb 2005, at 20:12, Tim Bray wrote: PaceRepeatIdInDocument Lots of discussion, more -1's than +1's. DISPOSITION: No consensus, close it. But now we have a problem, in that this removed ambiguity in one direction, just closing it leaves the ambiguity. So the only logical conclusion is that the WG is directing the editors to put language in that explicitly forbids entries with duplicate atom:id in an atom:feed. Mhh. First off that pace does not speak about allowing more than one id per entry, but rather of allowing more than one entry with the same id in a feed document. Secondly clarifying the spec the way you are doing does not take into consideration the consequences of doing so. These consequences include many other paces which have received many -1s for many reasons. But the main consequence is that the spec will not be finished in time, as you will be opening the debate of archive formats. Allowing this pace through, solves the archive problem that is required by the Atom Charter. I think there should be serious discussion of why this Pace is not thought to be appropriate. I don't think there are ANY good arguments against it. Henry Story
Re: PaceRepeatIdInDocument
PaceRepeatIdInDocument +1 over any attempt to clearly specify that it is not allowed to be repeated. It is better to be clear than to be ambiguous. But it is better to be ambiguous than to close the doors on rich possibilities just for the sake of clarity. This proposal is clearly better than the counter proposal asking for a limitation: - the counter proposal is forced to invent all kinds of new entities such as archive feeds to accomplish the goals of the charter. These are not needed either by the ambiguous current spec, or of course by one that applies this proposal - the counter proposal is making life more difficult for deployers of atom who instead of just being able to paste their new entry into a feed document must now verify that that document not have another entity with the same id. Henry Story
Re: Rehashing? Why is link required in entry?
On 11 Feb 2005, at 22:40, Norman Walsh wrote: The options as I see them: 1. I could lie. According to some people in this group there is no way you can lie, since there is no semantics to atom, it is just pure syntax! For something to be a lie it has to misrepresent the truth, and for that to happen, there has to be a relation between the vocabulary given and the world, ie a semantics! Henry
Re: BAG Question: What is a feed? Sliding-Window or Current-State?
updated2003-12-13T18:30:02Z/updated /entry /feed There are indeed two versions of the entry at one point in time with the same funcIds specified above, but as you also rightly point out two *different* equivIds. An atom:feed document is a representation of a single feed resource at a single point in time. ok. Aggregators do not consume feed resources -- they consume an iterative set of overlapping feed representations. Aggregators are therefore required by Atom to only include the latest version of an entry within their own resource representations. Only if you reduce the toolset available by requiring no one use a funcId relation. Otherwise it is quite possible to have multiple versions of an entry in the same feed as I clearly showed above. I believe that these requirements reflect the desires of most of the participants in this working group, so it seems to me that the question has been answered. Now is the time to question this statement. I would like to start by an obvious objections someone is bound to make to the example file system layout I described above, namely that it is much too complicated for most end users [2], and that most blog layouts will only have a simple, non versioned, layout. Something more like this: 2005/02/07/entry03-- a directory resource for the entry 2005/02/07/entry03/entry.xml -- the xml version of the entry 2005/02/07/entry03/entry.html -- the html version of the entry 2005/02/07/entry04/ -- a directory resource for another entry 2005/02/07/entry04/entry.xml 2005/02/07/entry04/entry.html If the id were to point to the http://bblfish.net/2005/02/07/entry03/ resource, as one would be tempted to do, then this would clearly imply a [Equivalence ID] interpretation of id, and so of course having two differing entries with the same id in a feed document would be saying something contradictory and false. This is an obvious intuition, that I myself followed for a long time. But of course this does not take into account this groups very long and convoluted discussions concerning the Identity Constructs, and the discussions about what an id really should be: should it just be a String? A String that can be seen to be a URI, but should not be thought to be one? ... Many people have vocally tried to limit the URIs allowed for an id to the set of URIs that are *not* URLs. In fact the default example given in the spec does not use a URL but some 'vemmi' URI. Non URL URIs such as 'vemmi' URIs are needed to create a non temporal identity of an entry that allows even simple file system layouts such as the one just shown to be given an id that makes sense in the [Functional ID] interpretation. Here is how the feed can be composed of such entries without this raising any special problem. feed... entry titleAtom-Powered Robots Really Run Amok/title link href=http://example.org/2003/12/13/atom03/ funcIdvemmi://example.org/2003/32397/id updated2005-02-07T09:30:02Z/updated /entry entry titleAtom-Powered Robots Run Amok/title link href=http://example.org/2003/12/13/atom03/ funcIdvemmi://example.org/2003/32397/id updated2003-12-13T18:30:02Z/updated /entry /feed Since entries here described are just versions of the vemmi://example.org/2003/32397 atemporal entry. So without trying to work out or guess what the changing desires of this working group are (I myself moved from one side to the other on this issue), I think we should rather try to decide on by weighing as Bob Wyman did, the advantages of each. And if this still does not allow one to choose one should perhaps just allow both. Henry Story Ps. If you do read this please send me a postcard, or short e-mail :-) Cheers, Roy T. Fieldinghttp://roy.gbiv.com/ Chief Scientist, Day Software http://www.day.com/ [1] _entry is a blank node as indicated by the leading '_' The graph is a simplified version of a full model for purposed of focusing on the current problem The atom example is the one available here: http://atompub.org/2005/01/27/draft-ietf-atompub-format -05.html#rfc.section.1.2 or here http://tinyurl.com/58z6g [2] though I wonder really how much weight arguments like this should have on IETF (Internet *Engineering* Task Force) groups, where we are already in the process of writing a huge spec, that requires understanding if HTTP, XML etc, none of which are that simple...
Re: PaceArchiveDocument posted
I think that the complexity that this proposal is proof of its failure. If you look at a Feed document as simply a sliding window view into the historical state of entries instead a sliding window view into the current state of entries (though as I have shown these can overlap),` then you have your archive document already. HELLO GUYS/GALS YOU ARE THERE AT THE FINISH LINE. IT ALL WORKS! One of the arguments against the sliding window view in the historical state of entries is that it was too complicated. But clearly not going that way is making things WAY MORE COMPLICATED. So before proceeding any further it may be worth now comparing the complexity of both proposals in detail. My guess is that the historical one is just a little surprising, but that is all. Henry Story
Re: PaceArchiveDocument posted
On 7 Feb 2005, at 18:29, Antone Roundy wrote: The latter seems likely to be supported by the WG, but the former does not. I'd rather have an archive document type, and not repeat entries in normal feeds. I don't think the historical sliding window view forces you at all to duplicate the entries in your feed. The spec allows you to remove all the old versions if you wish. After all the Present time, is just one element in the sequence of history. People who only want to live in the present don't negate history. They just don't remember it. Henry Story
Re: PaceFeedRecursive
On 19 Jan 2005, at 10:38, Henry Story wrote: I think the easiest way to get what you want is a 2 step procedure: 1. Merge the Head with the Entry constructs. They are not different enough for the difference to be important. 2. Make a Feed a subclass of Entry, with the extra property of being able to point to a Entry (Since a Feed is a Entry, it also points to other Feeds) I am +1 on such a refactoring. Nothing will be lost doing this, and a lot gained in simplicity. Henry I now no longer believe 2. Is needed. 1 would be quite neat though. Henry
Re: PaceEntriesElement
-1 I agree. Recursion can be placed in the model. It does not need to be in the syntax. In any case this is too big a change too late in the game. Henry On 7 Feb 2005, at 21:08, Antone Roundy wrote: -1: recursion is too complex and bulky.
Re: Call for final Paces for consideration: deadline imminent
On 5 Feb 2005, at 00:34, Robert Sayre wrote: Antone Roundy wrote: 3.5 Identity Constructs An Identity construct is an element whose content conveys a permanent, universally unique identifier for the resource (instantiated|described) by the construct's parent element. An Atom Document MAY contain multiple (revisions|versions) of the same resource, in which case the content of the Identity construct for each would be identical. Applications MAY decline to display more than one version of each resource. Comments? Preferences? Better ideas? Is it ready for a Pace? It doesn't make a bit of sense unless you define entry and feed, as has been pointed out numerous times over the past few days. This text is defining a feed in the text on atom:id, which should be short. If you define feed as a sliding window on a stream of entries, your definition makes sense. If you define feed as a server-determined representation of the current status of a set of entries, then it only makes sense to include one entry per atom:id. I would argue the second definition makes a lot more sense and accurately reflects real-world usage, where even the RDF formats recommend against repeating rdf:about. I would argue that you are completely wrong on this one. It is the first sliding window version that represents current usage a lot better. When people move their feed document to the archive, the easiest way to do this, is just to copy the live feed document over to a new timestamped file and change the next and previous links. Your suggestion would mean they would have to go through all the archived versions (the feed documents you get to by following the next links in sequence), and eliminate all duplicate entries. That is a lot more time consuming. I find it really good in fact that people should be able to keep a history of the changes they make to their entries. That is the honest thing to do. Those who want to cheat can also get what they want by deleting previous entries. But it will require more work. In any case the current system is I think very well defined. I am +1 on it remaining this way, and would be seriously distraught at seeing it go. I am in fact amazed that this should come up so late in the discussion here. No wonder this group can't get any further along. The basic model is not even agreed to by everyone. As for the whole text on Identity constructs it is again one of those useless pieces of text that the group is forced to write out because of its refusal to use the appropriate tools. If you had used RDF as a model for what you are trying to write then you would long ago have finished the document, and it would be a lot shorter and clearer too. Henry Robert Sayre
Re: Entry order
Having started agreeing with the initial post, and having read more of the thread I am now divided about what the best position is. In some sense the order is of the entries should not matter. All the important data to order the entries is in the entries themselves given by the modified date, the creation date, ... So if we map a whole feed into an rdf graph nothing is lost. We can use the data in the graph to sort our entries as we wish. On the other hand an application reading a feed would expect the latest entries to be at the head of the feed. This is very important at the protocol level, because without this guarantee, a client that would like to present the latest version of an entry would be forced to read the whole feed document and all feed documents linked to it, in order to be able to correctly assess that the entry it has really is the latest one. I think imposing a fixed ordering is not very helpful. Services may pop up that order entries in different ways depending on the interests of the receiver. But perhaps there should be a way to specify what the order of the entries is, or at least give a way to specify that the entries are ordered inverse chronlogically by the modified date when they are. This may be a protocol issue, or it may just be a matter of adding a special info to the feed to specify its ordering. Henry Story http://bblfish.net/ On 4 Feb 2005, at 20:27, Walter Underwood wrote: --On February 3, 2005 11:21:50 PM -0500 Bob Wyman [EMAIL PROTECTED] wrote: David Powell wrote: It looks like this might have got lost accidently when the atom:head element was introduced. Previously Atom 0.3 said [1]: Ordering of the element children of atom:feed element MUST NOT be considered significant. +1. The order of entries in an Atom feed should NOT be significant. This is, I think, a very, very important point to make. -1 Is this a joke? This is like saying that the order of the entries in my mailbox is not significant. Note that ordering a mailbox by date is not the same thing as its native order. Feed order is the only way we have to show the publication order of items in a feed. I just looked at all my subscriptions, and there is only one where the order might not be relevant, a security test for RSS readers. That is clearly not within Atom's charter, so it doesn't count. wunder -- Walter Underwood Principal Architect, Verity
Re: Posted PaceEntryOrder (was Entry order)
On 5 Feb 2005, at 11:20, David Powell wrote: This specification assigns no significance to the order of atom:entry elements within an Atom Feed Document. Atom Processors MAY present entries in any order, unless a specific ordering is required by an extension. Given a model of only informative metadata extensions this wouldn't be valid, unless the spec said that the order was significant, then it would be acceptable to communcate a preferred display order using extensions. The question is basically, if I have a database does it need to preserve the sequence number of the entry within a document? You put this in terms of databases and I put the question in terms of graphs (which if you have an rdf database to store your triples comes to the same thing). And my feeling is here that we should not have to keep the sequence numbers of the order of the entries in the document. Perhaps this is what Roy Fielding is getting at when he speaks of there being confusion on this list between the data model and the interaction model. It is important for clients when they ask for a sequence of entries to know what the order those entries are coming in. This can save them a lot of processing time. But it should not be part of the syntax to specify a preferred order of the entries. Display order is a different matter, but for the option of lexical order, then the answer would need to be yes, but I don't think it would be worth it. Display order on the client will also completely depend on what the client is trying to do. If the client is just interested in archiving all the entries, then any new feed be it an old one or a new one will be of interest: it will just be added to the database. If the client is interested in displaying the changes in a gui, this again may be completely up to the user. Some users may want only to see entries that they have read that have changed, as this may show a change of position of interest to them. Henry Story -- Dave
atom extensibility: Re: Don't mess with HeadInEntry!
I don't have that much of an opinion now on the head in entry and various other proposals. But I do find your comment that moving something off to an extension essentially kills it to be a very important remark. This is clearly to say that Atom has not yet dealt with the extension part of the charter. And even though many people seem to willing to create fill in language for that part of the spec to make it seem like this part has been addressed, your on the ground initial reaction is the correct one: there is no well defined extension mechanism. So perhaps what we could do in the next weeks is fill in the work I started in my proposal AtomAsRDF, that would allow Atom to be seen as an RDF/XML document, though one constrained by an Relax-NG syntax. This will require a week or two of serious group effort, but then extensions will fall out from the RDF side of things. In the mean time I am fully behind every movement to remove non core elements from Atom. Lets have a clean spec well defined spec. When enough people are left outside of the core, then I am sure talk of extensions will finally get to be serious. Henry Story On 4 Feb 2005, at 09:29, Bob Wyman wrote: We decided to support HeadInEntry. It doesn't make sense to back off now. Deferring HeadInEntry to a non-core extension essentially kills it and ensures that Atom use will provide virtually no advantage to anyone who is building aggregated feeds.
Re: Proof-of-concept RDF mapping for Atom
Have you had any more luck with this part of the mapping? Is this a problem with the current Atom syntax if not? Henry Story On 28 Jan 2005, at 22:27, David Powell wrote: I think it handles everything except for xml:lang - I'm not sure what's happening with xml:lang at the moment - but it should be possible to add it in a similar way to xml:base.
Re: atom extensibility: Re: Don't mess with HeadInEntry!
On 5 Feb 2005, at 13:49, Henry Story wrote: So perhaps what we could do in the next weeks is fill in the work I started in my proposal AtomAsRDF, that would allow Atom to be seen as an RDF/XML document, though one constrained by an Relax-NG syntax. This will require a week or two of serious group effort, but then extensions will fall out from the RDF side of things. I was just looking at the RSS1.1 [1] spec again and noticed that this is exactly what they have done. They have: - a Relax NG syntax to constrain the syntax - an OWL ontology to describe the model I think this is a very good example. I am not completely happy with their model, but this just seems so easy and so clean. Please have a look at it. Henry [1] http://inamidst.com/rss1.1/
Re: Call for final Paces for consideration: deadline imminent
On 5 Feb 2005, at 18:27, David Powell wrote: I disagree, as I've said before. The only literal interpretation is that you can't serve the same entry twice with the same id. We know it doesn't mean that, but the spec just doesn't define in which axis unique is meant to apply. I think that the problem is that the term 'entry' is used to refer to two different concepts. An entry id is identifying the underlying entry resource. But something like an entry title, I would think of as a property of the 'entry instance'. Currently we don't distinguish between entries and entry instances, and I think that this creates a lot of ambiguity. I agree with this analysis. But I think one can deal with it. A simple OWL ontology would make these things very clear. Although we could keep the model we have (let's call it the 'mutable entries' model), it isnt clear on a number of issues. Eg, if an old version of an entry has some property that isnt present in a newer version, does that property still apply to the new instance? The answer is presumably 'no' but it isn't obvious from the spec. Under a 'multiple instances' model, it would be implicit. It is easiest if one starts off deciding that no properties get inherited. Some properties do seem to clearly require inheritance such as the author, as one would expect all the versions of an entry to have the same author. But the amount of debating that this would require would not be worth the effort. The id property does the job very nicely and inconspicuously. At one point I had thought that properties such as author should be directly attached to the id construct, since they are immutable. But then one gets into problems of which are essential and which non essential properties... Henry Story -- Dave
Re: Posted PaceEntryOrder (was Entry order)
On 5 Feb 2005, at 18:48, Mark Nottingham wrote: On Feb 5, 2005, at 4:38 AM, Henry Story wrote: You put this in terms of databases and I put the question in terms of graphs (which if you have an rdf database to store your triples comes to the same thing). And my feeling is here that we should not have to keep the sequence numbers of the order of the entries in the document. Very well said, with emphasis on have to; they shouldn't be prohibited from doing so if they want to (and I don't think you're saying otherwise). yes, but perhaps if these were to be kept in the database they should not be saved as a direct property of the entry, but as a relation that the entry has to an event of document fetching. I am thinking here about the parallel with search engine results. The results you get from a search engine will be ordered in some way. This is inevitable. But one should be careful not to think that generally the results have any intrinsic meaning. Certainly not intrinsic in the sense that these would usefully be thought of as being properties of the web pages themselves. They are rather a factual statement about an order given by the search engine when you made a request at a certain time. Continuing along this line of thought, if you made a request to your favorite search engine to return its results in last changed order (and perhaps narrowed your request down to a specific site) then the order of the results could help you come to conclusions much faster. If could save you for example having to search through all the results if you were only looking for entries that had changed in the last day. Once you reached results that had changed before that, you would be sure that all other results were no longer relevant. I think this is probably what Roy fielding meant recently when he spoke about the difference between the model and the interaction model. In any case this should be something that one specifies at the protocol level. Henry Story Display order on the client will also completely depend on what the client is trying to do. If the client is just interested in archiving all the entries, then any new feed be it an old one or a new one will be of interest: it will just be added to the database. +1 Cool sometimes I also get +1 :-) -- Mark Nottingham http://www.mnot.net/
Re: atom extensibility: Re: Don't mess with HeadInEntry!
On 5 Feb 2005, at 20:18, Bob Wyman wrote: Roger Benningfield wrote: Henry: I suspect that Bob's reaction would have been the same, no matter how well-defined the extension mechanism. Anything outside the core will have spotty (at best) support in aggregators and publishing tools. You are absolutely correct. While I think I feel just as strongly as Henry does that there is a need for a well defined and robust extension mechanism, I also know from past experience that implementation of most extensions is vastly less probable then implementation of core features. Good. My feeling that HeadInEntry or Feeder should be in the Atom core is completely independent of my feelings concerning the utility of and desirability of a robust extension mechanism for Atom. Frankly, I'm a bit miffed by the idea that Henry, or anyone else, could have attempted to highjack my concern for what is core and suggest that this implies how I feel about some other mechanism. The cause of extensibility is not enhanced by such underhanded rhetorical trickery. Yes, but perhaps if everyone's favorite feature were possibly to be left to an extension, then people would be thinking more carefully about getting that very important part right. This is a little like the thought behind Rawl's Theory of Justice. If you set out to build a good political system, you should try to think of it from the point of view of someone who does not know what position he will have in that society. It helps focus the mind on the plight of the poor. Similarly here, everybody is so concerned to get their bit in the core spec (everyone wants a constitution where thinking they will start of as billionairs) that they don't care to make the extension mechanism clear and well defined. bob wyman Well to tell the truth I don't understand what the fuss about the head element in the feed is (which is not quite to say that I am fully behind the head_in_entry). I think the head element is just a special entry. Henry Story
Re: New Pace: PaceAggregationInSeparateSpec
On 4 Feb 2005, at 09:05, James Snell wrote: Bottom line: In my opinion, the parent feed is just as core to the entries metadata as is the date it was updated or any of the other core elements. It *could* be defined as an extension, but I feel it is better handled in the core. I have heard interesting arguments It's all about the Entries, stupid! that made the opposite assessment: namely that the entries are what is important, and that what feed an Entry is part of, is a accident of life. The idea there is that Entries are the stand alone entities. They can be made to be part of any feed whatsoever. A feed in this conceptualization, is a little like a search engine result listing where the pages they refer to are like entries (notice that search engine results pages are just a type of web page too). Which feed your entry appears in will depend very much on the type of query the user of the search engine made. Of course if an entry has a tag such as origin (which used to be on the table) then the entry it points to would be part of the metadata of the entry and so be a legitimate way of creating special selection of entries. Henry Story
Re: Call for final Paces for consideration: deadline imminent
A really clear way to specify this is to say that an id is a functional relation between an entry and a identity construct. This implies: -An Entry can only have one id. -Different Entries can have the same id. Of course because there is a bit of a confusion as to what is meant by an Entry the above sounds paradoxical. It is a bit like the relation the body of a US citizen has to a social security number. The body of a US citizen at a time has a functional relation to a SS number. Any such body has only one SS number. But because when we eat and breath our bodies change it turns out that different bodies have a relation to the same SS number. The different bodies, are time slices of the same US citizen. The group of these time slices is identified by the social security number. So that the relation between the SS number and set of such citizen slices, namely the relation between a SS number and the citizen is both functional and inverse functional. When this group speaks about an Entry as it appears in the Feed feed entry idtag:bblfish.net/entry1/id ... /entry ... /feed you are really speaking about an entry version. But because when people sit down and write an entry they are looking at the present version of the entry, and this is what they use to identify the sequence of entries that form the unique Entry over time, there is a confusion of what is being talked about. It is a little as if I spoke to someone and identified the body I am seeing at present with the person that body is a temporal part of. So when above I say: -An Entry can only have one id. -Different Entries can have the same id. What we mean is - the Entry Version can only have one id - any two Entry Versions that have the same id are different versions of the same Entry. So now one should define what that type of entry is. And that is simple. It is the Collection of all Entry Versions that have the same id. Henry On 4 Feb 2005, at 22:10, Mark Nottingham wrote: Graham, the issue here is that the spec can be interpreted in a number of ways, which is not good. You seem to agree with that below, correct? Separately, there's the issue of what it *should* say. Tim and now you say that you have a good idea of what you want it to say; I'd be very interested to see how you'd specify that. Can you suggest some spec text? On Feb 4, 2005, at 1:00 PM, Graham wrote: On 4 Feb 2005, at 8:44 pm, Mark Nottingham wrote: I.e., just because it's a permanent, universally unique identifier doesn't mean you're not able to use it twice to talk about a single entry; I disagree, as I've said before. The only literal interpretation is that you can't serve the same entry twice with the same id. We know it doesn't mean that, but the spec just doesn't define in which axis unique is meant to apply. Graham -- Mark Nottingham http://www.mnot.net/
Re: Revised PaceIconAndImage, added PaceMultipleImages
I am +1 on having images, or what I call entry illustrations. BlogEd has those, and they work nicely. See http://today.java.net/jag/ or http://bblfish.net/blog for blogs that use them. Notice that the top entry (the Feed itself) has an illustration too. Which is another hint that a Feed is a subclass of an Entry. Of course if they did not make it into the spec it would be easy to add them as extensions. So the effort in speccing this would not be wasted. You may want to consider that an icon of an image is also related somehow to the original. In the feeds mentioned above, clicking on the icon brings you to a the original image the icon is a representation of. In one case [1] it occurred to me that have been more intuitive to have clicking on the image bring up a video. Henry Story [1] http://www.bblfish.net/blog/page3.html#25 On 2 Feb 2005, at 07:49, Tim Bray wrote: Having produced my own Atom feed has made me a supporter of this Pace; without getting too deep into it link rel=self feels quite sensible, while link rel=icon feels stupid. However, this Pace needed work; first of all, it was based on link constructs, which no longer exist. So I revised it. Second, along with turning Icon and Image from link into their own elements, it changed the cardinality, allowing more than one atom:image in atom:head. I think this is probably a bad idea, but I'm 100% sure that it's wrong to mix up this with the (entirely separate) debate on whether to use image instead of link. So, I ripped it out of PaceIconAndImage and created a new PaceMultipleImages to suggest this. Third, along with these other changes, the Pace changed the atom:image aspect ratio from 2:1 to 1:1. Once again, this may be a good idea, but it needs discussion. But I kind of think this may have been a cutpaste typo, so I ripped it out but didn't create a new Pace, if someone really wants to change the Aspect ratio they should create a Pace. Having said all that, I'm +1 on PaceIconAndImage. I'm -1 on PaceMultipleImages, this is an experimental feature, Atom, doesn't need those, YAGNI. -Tim
Re: tagline - subtitle
Why not go one step further in generality and call the tagline the summary? Then we will be closer to the point I had been making in PaceEntriesAllTheWayDown2, and one step closer to showing that a Feed head is the same structure as an Entry. Or if you go the Fielding way with the recursive pace, that a Feed is a structure that is a subclass of the Entry structure. And then we will really cut the length of the spec down to its core. Henry Story On 2 Feb 2005, at 17:17, Julian Reschke wrote: Graham wrote: Any chance of renaming atom:tagline to atom:subtitle? The two sample feeds posted today have the taglines ongoing fragmented essay by Tim Bray and WebDAV related news. Aren't taglines meant to be funny or catchy or clever? The relevant definitions from dictionary.com are: tagline: An often repeated phrase associated with an individual, organization, or commercial product; a slogan. subtitle: A secondary, usually explanatory title, as of a literary work. The second seems much broader and more useful, and there's nothing stopping you using a slogan as subtitle. +1
Re: PaceExtendingAtom
-1. At least I don't see why there should be limitations at all on where extensions can appear. I am for a general must ignore rule. On the other hand I think a much more ambitious extension spec would be one Atom were defined by something similar to the RELAX NG description we currently have and an OWL ontology. This would be helpful and very useful. PaceExtendingAtom as it currently is stated is restrictive without being useful. Henry Story On 13 Jan 2005, at 19:27, Tim Bray wrote: +1 I wrote it and I still think it's necessary as a bare-minimum measure. -Tim
Re: tagline - subtitle
On 2 Feb 2005, at 18:09, Antone Roundy wrote: On Wednesday, February 2, 2005, at 09:49 AM, Henry Story wrote: Why not go one step further in generality and call the tagline the summary? Then we will be closer to the point I had been making in PaceEntriesAllTheWayDown2, and one step closer to showing that a Feed head is the same structure as an Entry. Or if you go the Fielding way with the recursive pace, that a Feed is a structure that is a subclass of the Entry structure. And then we will really cut the length of the spec down to its core. Because it's not a summary, which shows that a Feed head isn't quite the same thing as an Entry. You mean you don't see it that way yet ;-) It would be conceivable, though perhaps not advisable (I'd have to think about it), to add a subtitle element to entry, but I can't really see adding a summary element to feed. On 2 Feb 2005, at 18:09, Sam Ruby wrote: I'm ambivalent w.r.t. tagline vs subtitle; but changing the name to summary to impose a structure that isn't there doesn't feel right to me. It's just data is a tagline. It could conceivably be a subtitle. But it is a summary of what exactly? Ok. I can agree that a tagline is not a summary. Adding a summary element to a feed does not seem wrong. Consider James Gosling's blog: http://today.java.net/jag/ The following does not seem out of place as a summary of the feed: I've been inescapably tagged as the Java guy. These days I'm the CTO of Sun's Developer Products group. This now includes the J2SE engineering organization, so I've managed to cycle back. With luck I'll update this blog often enough for it to be interesting. And if you think that an Entry can be the object of a lot of discussion, and so have responses attached to it, then you can come to see that it would not be so silly to have an Entry have a tagline... Henry Story Henry Story On 2 Feb 2005, at 17:17, Julian Reschke wrote: Graham wrote: Any chance of renaming atom:tagline to atom:subtitle? The two sample feeds posted today have the taglines ongoing fragmented essay by Tim Bray and WebDAV related news. Aren't taglines meant to be funny or catchy or clever? The relevant definitions from dictionary.com are: tagline: An often repeated phrase associated with an individual, organization, or commercial product; a slogan. subtitle: A secondary, usually explanatory title, as of a literary work. The second seems much broader and more useful, and there's nothing stopping you using a slogan as subtitle. +1
Re: PaceExtendingAtom
[[ Also, Person Constructs, the atom:head element, and the atom:entry element allow the inclusion of foreign markup. ]] If one could add foreign markup anywhere then the above sentence would be redundant. Henry Story http://bblfish.net/ On 2 Feb 2005, at 20:01, Joe Gregorio wrote: How is PaceExtendingAtom restrictive? It only spells out a Must Ignore policy and nothing else. Am I missing something? -joe
Re: Dereferencing Identity Constructs
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 version of the feed or entry may be found. I'm +1 on this, -1. And I *will* lie down in the road. For 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 absolutely be dereferenced, but only in its link role. The language above could be read as discouraging what I'm planning to do, and what I'm planning to do is perfectly good practice. Anyhow, per both IETF RFCs and the W3C web-architecture spec, no harm can be done merely by trying a GET on any URI, so saying SHOULD NOT is just bogus. I was thinking of doing something similar with BlogEd. An entry id would point to the directory containing each version of an Entry. The link would probably point to the exact Entry version described by the atom xml entry in which it appears. By dereferencing the id link one could with correct access permissions, see all the versions of an entry. Though the usual behavior would be to default to the last one. Perhaps a directory tree like this 2005/01/31/entry1/ the id of all the entries below 2005/01/31/entry1/version1/ the url of the link to the first version 2005/01/31/entry1/version1/entry.xml my first published entry in atom xml 2005/01/31/entry1/version1/entry.html first published entry as html 2005/01/31/entry1/version2/ the url of the link to the second version 2005/01/31/entry1/version2/entry.xml my first published entry in atom xml 2005/01/31/entry1/version2/entry.html first published entry as html so when, with a browser, you request http://.../2005/01/31/entry1/ you would always get the latest version of the Entry in the format of the mime type requested. And when you request http://.../2005/01/31/entry1/version1/ you get the first version of your entry in the format of the mime type requested. So my belief is also that if people really don't want id dereferenced they should use a scheme specifically for that purpose. Those who do that may well have much longer lived web sites, and their blogs may be more flexible in that they can be moved from one server to the next -- but they may also be a lot more difficult to find. One way to get people to have their cake and eat it too, may be to allow multiple id tags. Since an id is an inverse functional relationship between an Entry a Resource this should not cause any trouble. In any case there will never be any way you can limit the number of names a thing has. Henry Story
Re: Proof-of-concept RDF mapping for Atom
On 30 Jan 2005, at 02:31, David Powell wrote: [snip] I meant, although: XML --[XSLT]-- RDF/XML --[RDF/XML-parser]-- RDF-model ...is an ok reference implementation for demonstrating an RDF mapping, the mapping should be defined in prose, because: XML --[SAX]-- RDF-model ...would be a lot more efficient and doesn't have so many dependencies. So basically you could navigate the Atom document, and add appropriate statements to an RDF model using the model API. This sounds very much like saying that it would be easiest if one could interpret Atom directly to be RDF, as proposed by AtomAsRDF. This can be brought back to the question of how to choose the a model to map Atom to. Here are some initial possibilities: - choose RSS1.0 or RSS1.1 as the model. Being so flexible it should be quite easy to map Atom to those flavors of RSS. If that were possible, then this would be just another way of saying: anything you can say in Atom you can say in RSS1.x - create some new model to map atom to: in which case you have to invent a whole new model and go through all the problems of working out the consistency of your model that this group has gone through with Atom. In any case the model you come up will either be: a. more expressive than Atom: you can express more in the model than you can in Atom. b. less expressive: when mapping from Atom to this model you will loose information c. isomorphic with Atom: you can map from atom to your model and back without information loss either way. If your model is a. more expressive or b. then this will not prove to be a good foundation for explaining extensibility clearly, since you will loose information either by mapping to the model or by mapping back to Atom. So really what we require is an isomorphic model. And the isomorphic model that would be the easiest to understand would clearly be the identity model where Atom can be interpreted as RDF. We are not quite there. There is a mapping from Atom to something very close to Atom, so close I argue that the Atom working group could easily take a few steps to make the mapping be the identity map. Henry Story http://bblfish.net/
Re: I-D ACTION:draft-ietf-atompub-format-05.txt
On 28 Jan 2005, at 15:14, Danny Ayers wrote: On Thu, 27 Jan 2005 16:10:06 -0500, Robert Sayre [EMAIL PROTECTED] wrote: http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.txt Thanks Robert. The Relax NG snippets make a *huge* difference to the clarity. (Thanks Norm!). Yes. A real pleasure to read now :-)
Re: PaceAttributesNamespace is *not* about syntax!
Thanks for the reply, Sam. I think the misunderstanding has mostly to do with the fact that we have similar but slightly different aims. We should try to clearly establish our respective aims and find the points we have in common, so that we can agree to solve the points we have in common quickly and easily. On 27 Jan 2005, at 03:39, Sam Ruby wrote: Henry Story wrote: On 26 Jan 2005, at 15:03, Sam Ruby wrote: [...] But, now lets examine the statement proposed in PaceAttributeNamespace. It essentially alerts producers of something that that they need to be aware of. Now a quesion: what do they need do different with the knowledge that the RDF mapping does this? I would assert the answer to this question is nothing. Meaning that this particular statement is not needed. Again, no issue with the mapping. No issue with describing the mapping alongside with the actual mapping. I think your assertion is wrong. If they are consuming or producing extended Atom [1] they will know exactly what these extensions are referring to. It won't affect in the least consumers of simple, non extended Atom, but it will greatly help consumers and producers of extended atom. Now if you don't care about making their lives easier, then you have nothing to worry about in this pace. If you do, like I and many others, then this will be very helpful. It seems to me that you are both misunderstanding and mischaracterizing what I am saying. Furthermore, in other emails, I sense a confusion between RDF (which is a model) and RDF/XML (which is a syntax). No worry. I think we all know the difference there, but the language does lend itself to confusion. I am in favor of AtomAsRDF (as a way to model this data). I am opposed to AtomAsRDFXML (as a syntax for expressing this model). Ok. I am in favor of AtomAsRDF(Model) too. But I am trying to go a little further to AtomAsRDFXML (as you put it) because - The spec can very nearly already be interpreted that way - defining another mapping from xml to RDF, though possible, is a lot of work, and we just don't have the time - it will allow for the easiest way to explain extensibility of Atom So though I think (and I have recently myself tried out some ideas on this subject) there may be some general mapping rule from xml to rdf that are much closer to the general users intuitions about xml, I think that when the xml is written as atom currently (nearly) is, we have something that does map to a graph and that will map to the same graph than any more intuitive mapping than rdf/xml would. If anybody is up to the task, I am for inclusion of prose into the standard describing how one is to interpret Atom feeds as RDF. Any such mechanism that accomplishes this will, by necessity, need to specify what namespace is used in the URIs used to define relationships. Well I liked your idea of adding a special section to the spec on how to interpret atom as rdf/xml, perhaps as part of the extensibility section. My feeling is that would be best if it explains how atom can be seen to be rdf/xml, because then explaining extensibility will be very easy: any atom document with foreign name spaced attributes or elements must also be an rdf/xml document when so interpreted And we then leave the complexity of that statement to the other specs out there. PaceAttributeNamespace does not do that. All it says is is that a given namespace may be used. For what purpose such a statement is made is entirely unclear. By contrast, a precise statement to the effect of how RDF aware tools MUST interpret Atom feeds if they are to interoperate is both clear and useful. Ok. Well I think we are really thinking very similar thoughts here. I would just add that we should try to see if the RDF/XML interpretation of Atom works out, because that will vastly reduce the amount of work we need to do in explaining the interpretation. (interpretation is an excellent word!) Henry Story - Sam Ruby
Re: PaceAttributesNamespace is *not* about syntax!
On 27 Jan 2005, at 15:28, Bill de hÓra wrote: Rudeness objection. One reaps what one sows. [1] I'm seeing genuine questions Since you are asking, I'll answer them. On 26 Jan 2005, at 4:37 pm, Henry Story wrote: I think your assertion is wrong. If they are consuming or producing extended Atom [1] they will know exactly what these extensions are referring to. It won't affect in the least consumers of simple, non extended Atom, but it will greatly help consumers and producers of extended atom. What will? To what does these extensions refer? How will it help who? Consider the problem of creating extensions to Atom. You are adding a new vocabulary to the current atom vocabulary, so you will have non atom name spaced elements or attributes in your extended atom document. feed entry titleAtom Robots run amok/title link href=http://example.org// my:illustration my:href=http://bblfish.net/blog/img.jpg; ... /entry /feed We are all agreed about what the above document means, stripped of the my:illustration tag. Parsers that only wish to concern themselves with those striped documents will have no trouble. The spec clearly specifies what is what. The problem is to clearly specify how extended atom documents like the one above are to be written consistently, so that they can be interpreted correctly, the way the writer of the document intended them to be. To what does these extensions refer? These extensions refer to attributes such as my:href in the example above. How will it help who? The problem is that attributes in atom are not namespaced. If they were then it would be easy to interpret the above document as an rdf document. An rdf document has very clearly specified semantics. Having these clearly specified semantics is very helpful to extension writers and consumers. The details of how it will help are much more difficult to explain in a short e-mail such as this. A hint is contained in the word onotology. This has to do with Objects. And there is a very strong relationship between OO programming and what is being proposed here. The benefits of OO programming are the same benefits we stand to gain here: it makes it much easier to create elements and specify how they can be combined. But it would perhaps be best to work through an example to help show how this works. Does this help? Henry Story [1] http://www.imc.org/atom-syntax/mail-archive/msg12038.html
Re: PaceAttributesNamespace is *not* about syntax!
On 26 Jan 2005, at 15:03, Sam Ruby wrote: [...] But, now lets examine the statement proposed in PaceAttributeNamespace. It essentially alerts producers of something that that they need to be aware of. Now a quesion: what do they need do different with the knowledge that the RDF mapping does this? I would assert the answer to this question is nothing. Meaning that this particular statement is not needed. Again, no issue with the mapping. No issue with describing the mapping alongside with the actual mapping. I think your assertion is wrong. If they are consuming or producing extended Atom [1] they will know exactly what these extensions are referring to. It won't affect in the least consumers of simple, non extended Atom, but it will greatly help consumers and producers of extended atom. Now if you don't care about making their lives easier, then you have nothing to worry about in this pace. If you do, like I and many others, then this will be very helpful. - Sam Ruby [1] Should we call these molecules?
Re: PaceAttributesNamespace is *not* about syntax!
Graham the Robot [1], when real people come and ask me something I'll talk to them. Henry On 26 Jan 2005, at 18:01, Graham wrote: On 26 Jan 2005, at 4:37 pm, Henry Story wrote: I think your assertion is wrong. If they are consuming or producing extended Atom [1] they will know exactly what these extensions are referring to. It won't affect in the least consumers of simple, non extended Atom, but it will greatly help consumers and producers of extended atom. What will? To what does these extensions refer? How will it help who? You seem to have given up trying to get your ideas across to other people. (+1 on Sam's argument, btw) Graham [1] http://www.imc.org/atom-syntax/mail-archive/msg11659.html
Re: AtomOWL AtomAsRDF
On 18 Jan 2005, at 02:18, Bill de hÓra wrote: Henry Story wrote: this implies the following rdf graph _e -entry- _E |-id--tag://sometag |-geo:x-10.1 |-geo:y-57.3 [On a technical point, I would disagree the graph is implied. As I said earlier, this kind of assumption concerns me.] It will be when the gap between atom as it currently is and where it would have to be for it to be correctly seen as RDF is closed. As you see there is not that much to closing the gap. And there are many ways of doing this, which need to be looked at, and evaluated for those that form the best compromise solution. If you look at the AtomOWL spec, you will see that among other things it is simply a specification of what types of objects a relation can take as subject and as Object. This is what I'm getting from the proposal - if range and domain for extensions are determined, a semantically 'consistent' (I won't say 'meaningful') extensibility framework for applying them to Atom structures can be established. So since we have evaluation rules above the level of data structures, we can determine if any extra metadata satisfies the constraints. Two things come to mind if that is a fair summary. First, I don't see how it can be done generally without RDF backed ontological modeling to begin with - which would be AtomIsRDF. Correct me if I'm wrong, but I think for this to work I would need to know what the essence of Atom domain constructs are before I can determine whether a new property can be correctly be applied to one. Yes, if I have understood you correctly. That is why I have AtomOWL which gives you the essence of the Atom domain constructs. For example it specifies that atom:id is functional, which says that two Entries are different if they have different ids. I have tried to express all the number constraints that the spec defines too, such as a Feed requiring one Header and no more. I call this AtomAsRDF rather than AtomIsRDF because the point is that we are trying to make this completely invisible for anyone who does not want to know, or has not yet had time to learn these constructs. Second, I've said before, my position is that Atom doesn't require extensibility. Tim for one, has taken umbrage with my use of the word 'extensible', but what you're proposing isn't far away from what I would mean by it - extensions and their relationships are processed through an evaluator. I just happen to think we don't need to spec this yet*. I think that the spec does speak about extensibility and a model for atom. With AtomAsRDF and AtomOWL I provide both. Even if we did not need this yet, it certainly won't harm to track the differences, and the obvious problems that some decisions entail. For example modeling the Person construct it is obvious that the e-mail address should be inverse functional and not functional as we have it now. Ie if we have 2 Person objects (be they in an author or contributor tag) anywhere in the xml with the same email address, we should be able to conclude that these are in fact the same person. The model sometimes also can help spot gaps in the spec, which cannot be a bad thing. It is better these gaps be found now than later when it will be difficult to change anything. So, I'm not -1 on this, but I do think it's out of scope. Ok. I take that as being that your kind of for it :-) By the way I think that there are many people out there who don't want to hear about RDF in so far as it is plastered all over their xml in big bold letters. They don't want rdf:li here and rdf:resource there. They don't want xml that is not in a nice tree shape, but just a set of statements about the relationship between things. They want to use XPath and other well tested tools. Apart from that they probably don't have anything really against RDF (apart from that one has the suspicion it could have been better done, but then that is true with all technologies - one need look no further than default namespaces in xml). So I think these people have nothing to worry about the current proposal. They have everything they want. And they have something extra: in their spare time they can learn about that weird thing called rdf. This would be seamless integration. And I think is the foundation of a good long lasting compromise. cheers Bill * I would include trying to make explicit whatever the child_of() evaluation rules might be for XML containership here.
Re: AtomOWL AtomIsRDF
On 17 Jan 2005, at 18:16, Dan Brickley wrote: [snip] I fear [2] is unfortunately named. Atom is RDF-like in some ways, but until the Atom spec says Atom is RDF, Atom isn't RDF. A surface similarity to RDF's XML encoding, or even to RDF's graph data model, isn't by itself enough to declare that Atom is RDF. For example, there have been threads here about defaulting, about data being implied if missing, and other things that have no clear RDF equivalent. The name Atom is RDF goes somewhat against the decision record of this group, which has been pretty clear in its non-RDFness. Wiki style tends towards the consensual, so I suggest renaming it to AtomRDF or similar. Yes, very good point. I have created a new Page called AtomRDF [3], whose aim is to track what would be needed for an Atom document to be an RDF document. It is only if we are clear about these that it will be possible to come to a reasoned decision on the value of perhaps bridging the gap. The gap is I think a lot smaller than most people think (which is what I was trying to emphasize with the AtomIsRDF name) But you are right, there still is one. Even as an RDF enthusiast, I find the name problematic. So I'm concerned that Atom is RDF will annoy people needlessly, which would be a shame since the work you've been doing on an RDF/OWL view of the Atom format is both interesting and valuable. Dan Henry Story [1] http://www.intertwingly.net/wiki/pie/AtomOWL [2] http://www.intertwingly.net/wiki/pie/AtomIsRDF [3] http://www.intertwingly.net/wiki/pie/AtomIsRDF
Re: Atom Link element: Failure
Ok, I give up on this task. I have just found that when there is a rdf:Resource you can't also have attributes. And that attributes have to be qualified. It is a real pity. It would be good to make a list of what we would have needed from RDF/XML to make Atom be rdf, and then work backwards to create RDF/XML2 where this works out fine. Henry On 10 Jan 2005, at 01:29, Robert Sayre wrote: Henry Story wrote: [snip] 4) Property attributes -- both hreflang, href and all the other properties of Link are unique, and given that they are string literals (subsets of them at least, but nevertheless) they can be move into attributes on Link Entry link rdf:parseType=Resource hreflang=de href=http://example.org/de/2003/12/13/Atom03/ /Entry Use of unqualified attributes is deprecated in RDF/XML (check the validator). My opinion is that the transformation you're looking for would be easier with XSLT. You are right. The validator at http://www.w3.org/RDF/Validator/ is really useful. [snip] It gets a POST with a fairly average atom entry, but there are extensions in funny places. Like most people, the server stores standard fields in a relational database, so there are columns for title, summary, etc. in a table called something like journal_entries. It would be fairly easy to store immediate children of entry in an unknown_xml field, and pass them through, but what about the other extensions? Using an RDF store might make this problem a lot easier, but I don't forsee a mass migration in that direction happening this year or next. You don't need a specialized RDF storage, though very good ones exist. There are schemes to map RDF into any relational database, just as there are schemes to map objects into relational databases. In fact most RDF storage tools in Java provide this. That's not my point. My point is that there's a staggering amount of data currently living in RDBMSes, and people aren't going to re-architect their storage to use Atom. I was not trying to get people to use RDF databases at the back end. I was just hoping that a well engineered XML document would with a little care also turn out to be a well engineered RDF document. That would provide maximum flexibility in that it would allow people to move into the rdf world seamlessly. Robert Sayre
Re: Atom Link element: Success
Ok, I don't know what happened to me there. I must have been overly tired. I went to do some weigh lifting, came back and found that my reasoning is in fact correct. In fact if you put in the following rdf ?xml version=1.0? atom:Entry xmlns:atom=http://purl.org/atom/#; xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#; atom:link atom:hreflang=de atom:href=http://example.org/de/2003/12/13/Atom03/ /atom:Entry in the validator you get the following graph: inline: servlet_77206.gif which is what I started off with. Henry Story On 10 Jan 2005, at 19:11, Henry Story wrote: Ok, I give up on this task. I have just found that when there is a rdf:Resource you can't also have attributes. And that attributes have to be qualified. It is a real pity. It would be good to make a list of what we would have needed from RDF/XML to make Atom be rdf, and then work backwards to create RDF/XML2 where this works out fine. Henry On 10 Jan 2005, at 01:29, Robert Sayre wrote: Henry Story wrote: [snip] 4) Property attributes -- both hreflang, href and all the other properties of Link are unique, and given that they are string literals (subsets of them at least, but nevertheless) they can be move into attributes on Link Entry link rdf:parseType=Resource hreflang=de href=http://example.org/de/2003/12/13/Atom03/ /Entry Use of unqualified attributes is deprecated in RDF/XML (check the validator). My opinion is that the transformation you're looking for would be easier with XSLT. You are right. The validator at http://www.w3.org/RDF/Validator/ is really useful. [snip] It gets a POST with a fairly average atom entry, but there are extensions in funny places. Like most people, the server stores standard fields in a relational database, so there are columns for title, summary, etc. in a table called something like journal_entries. It would be fairly easy to store immediate children of entry in an unknown_xml field, and pass them through, but what about the other extensions? Using an RDF store might make this problem a lot easier, but I don't forsee a mass migration in that direction happening this year or next. You don't need a specialized RDF storage, though very good ones exist. There are schemes to map RDF into any relational database, just as there are schemes to map objects into relational databases. In fact most RDF storage tools in Java provide this. That's not my point. My point is that there's a staggering amount of data currently living in RDBMSes, and people aren't going to re-architect their storage to use Atom. I was not trying to get people to use RDF databases at the back end. I was just hoping that a well engineered XML document would with a little care also turn out to be a well engineered RDF document. That would provide maximum flexibility in that it would allow people to move into the rdf world seamlessly. Robert Sayre
Re: Comment on process
I would like to agree with this. I have not had much of a weekend, and I am not sure I will be able to take so much time off work to put into this task. I am being paid to work on an open source blog editor, and I am not sure its ok for me to just spend all my time on this list. Also the proposal I put forward in the Closure on Extensibility RDF thread is itself really a process. I outlined 4 steps to test out my idea. I do not know if it will succeed, just that it would be very elegant if it did. It would help if some more experienced people than me put their head together to help out this process. But my feeling is that they won't bother if they feel that the opening was a sham one. Nobody wants to waste their time. So that is why I asked for a little good will. And I don't think that there should be any bad will, since what I am proposing should have very little impact on what those that don't want to know about RDF want. Henry On 8 Jan 2005, at 23:03, Danny Ayers wrote: I'm not going to argue the point here any further, but feel something has to be said. I am optimistic a compromise on the extensibility/RDF issue can be reached in the given time frame, but find the imposition of such a short period a bit extreme. It isn't that there hasn't been considerable work on RDF-compatibility, that side's potentially trivial (use RDF/XML!), it's the production of a compromise everyone is comfortable with.
Re: Closure on Extensibility RDF
The IETF document I mentioned is the one this mailing list is working on developing. The four points I listed are starting points for a couple of small additions to the Atom IETF document and their relation to a to be written OWL Ontology. There are I am sure people more familiar with the ins and outs of this standards process that will know how to turn that general idea into more specific and acceptable proposals. Henry On 8 Jan 2005, at 21:50, Paul Hoffman / IMC wrote: At 8:33 PM +0100 1/8/05, Henry Story wrote: Here is one suggestion I was thinking of to move along, quickly and seamlessly I hope. All that seems fine, but your list is neither a Pace nor an Internet draft, and is therefore not in line with what Tim and I asked for. Given that you talk about an IETF document, I am assuming that you intend to write the Internet Draft, yes? --Paul Hoffman, Director --Internet Mail Consortium
Re: Closure on Extensibility RDF
The internet draft I want to propose is an OWL document. I can get this out tomorrow. It will essentially say everything the current Atom OWL spec says, but in machine readable form. All that is required then is that the Atom IETF document this working group is working on have some language describing its relation to the OWL document. This need not be a very big change to the current document. I believe it could be done in a few sentences taking my first proposal as a guide. If anyone has some good ideas on where it would be best to change the language, please help me along and write that out. I can do with all the help out there :-) Understand that all I am proposing is a machine readable rewriting of what the current Atom spec says. That is most of what there is to it. The rest is just asking for a little good will. Yours sincerely, Henry Story http://bblfish.net/blog/ On 8 Jan 2005, at 23:35, Paul Hoffman / IMC wrote: At 10:54 PM +0100 1/8/05, Henry Story wrote: The IETF document I mentioned is the one this mailing list is working on developing. Then you didn't understand Tim's message. He meant a *new* Internet draft, not a change to the current draft (unless the change is a few sentences). From your list of changes, it doesn't seem like it is just a few sentences, so you need to submit a separate Internet Draft, initially as an individual submission. If the WG agrees that it should be a WG work item, it will change into one; otherwise, you can pursue it as an individual document, probably still discussing it on this mailing list. The four points I listed are starting points for a couple of small additions to the Atom IETF document and their relation to a to be written OWL Ontology. There are I am sure people more familiar with the ins and outs of this standards process that will know how to turn that general idea into more specific and acceptable proposals. See Tim's message. You do this by creating either a detailed Pace or a complete Internet Draft. --Paul Hoffman, Director --Internet Mail Consortium
Re: Closure on Extensibility RDF
On 9 Jan 2005, at 00:06, Henry Story wrote: The internet draft I want to propose is an OWL document. I can get this out tomorrow. It will essentially say everything the current Atom OWL spec says, Sorry it is past midnight here at I am typing a little fast. I meant It will essentially say everything the current Atom spec[1] says, [1] http://ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub- format-03.txt but in machine readable form. All that is required then is that the Atom IETF document this working group is working on have some language describing its relation to the OWL document. This need not be a very big change to the current document. I believe it could be done in a few sentences taking my first proposal as a guide. If anyone has some good ideas on where it would be best to change the language, please help me along and write that out. I can do with all the help out there :-) Understand that all I am proposing is a machine readable rewriting of what the current Atom spec says. That is most of what there is to it. The rest is just asking for a little good will. Yours sincerely, Henry Story http://bblfish.net/blog/ On 8 Jan 2005, at 23:35, Paul Hoffman / IMC wrote: At 10:54 PM +0100 1/8/05, Henry Story wrote: The IETF document I mentioned is the one this mailing list is working on developing. Then you didn't understand Tim's message. He meant a *new* Internet draft, not a change to the current draft (unless the change is a few sentences). From your list of changes, it doesn't seem like it is just a few sentences, so you need to submit a separate Internet Draft, initially as an individual submission. If the WG agrees that it should be a WG work item, it will change into one; otherwise, you can pursue it as an individual document, probably still discussing it on this mailing list. The four points I listed are starting points for a couple of small additions to the Atom IETF document and their relation to a to be written OWL Ontology. There are I am sure people more familiar with the ins and outs of this standards process that will know how to turn that general idea into more specific and acceptable proposals. See Tim's message. You do this by creating either a detailed Pace or a complete Internet Draft. --Paul Hoffman, Director --Internet Mail Consortium
Re: Closure on Extensibility RDF
I can't do everything simultaneously. Tomorrow I will give you a first version of an OWL document that will map the current atom spec. Can you give me the current namespace for the draft atom spec I am supposed to be working to? This is so the atom OWL document can describe the properties of the draft atom spec. The url of the location of the directory of the draft spec will probably do. Then I can define the properties of atom:content using the full url say http://purl.org/atom/#content When someone clicks on that link with a browser that asks for the content as text/simple they will get the current atom draft spec. When they ask for it using the mime type application/rdf+owl they will get the document I will present you tomorrow. With this document at hand it will be a lot easier to explain the relation between the spec and the OWL document, either in the current atom spec, or if you really insist, in a separate Draft. That will be machine interpretable xml, ie: running code. Good night, Henry Story On 9 Jan 2005, at 00:25, Paul Hoffman / IMC wrote: At 12:06 AM +0100 1/9/05, Henry Story wrote: The internet draft I want to propose is an OWL document. I can get this out tomorrow. It will essentially say everything the current Atom OWL spec says, but in machine readable form. An OWL document is not an Internet Draft. If you cannot create an Internet Draft, please find someone who agrees with your desires to help you. All that is required then is that the Atom IETF document this working group is working on have some language describing its relation to the OWL document. That should be included in your Internet Draft. This need not be a very big change to the current document. That remains to be seen. The best way we can see it is in your Internet Draft. Clearly, if it is a small change and the WG wants to use it, it can be folded into the main document before we send it to the IETF. I believe it could be done in a few sentences taking my first proposal as a guide. Great! Let's see them. If anyone has some good ideas on where it would be best to change the language, please help me along and write that out. That is actually the least important point in your proposal, and the easiest to take care of late in the process if the WG agrees to the incorporation. If the WG doesn't agree to the incorporation, it isn't needed at all in your Internet Draft. I can do with all the help out there :-) So can we all... Understand that all I am proposing is a machine readable rewriting of what the current Atom spec says. In order for us to verify that statement, we need to see the rewriting, and we need to hear from a few people who understand OWL saying yup, that exactly matches what is in the format draft. That is most of what there is to it. The rest is just asking for a little good will. Fully disagree. The rest is the WG coming to consensus on whether or not we want this as part of the baseline spec. Given this WG's propensity to disagree about most things XML and RDF, assuming that will come easily is not based on even a casual reading of the mailing list. --Paul Hoffman, Director --Internet Mail Consortium
arbitrary limitations in Person
I was just looking closely at the atom:Person class [1] and found some pretty arbitrary limitations: - why should a Person only have one e-mail address? - why should a Person only have one associated url? It seems to me that one should follow the principle: only impose limitations that are proven to be necessary. Here they seem both unnecessary and counterintuitive. Henry [1] http://ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub- format-03.txt
Re: Role of RSS in Science Publishing: Atom is in RDF format
I did not quite finish the last simplification (I had forgotten to remove a ParseType and a rdf:type). The result should have been Feed head titleExample Feed/title link href=http://example.org// updated2003-12-13T18:30:02Z/updated author nameJohn Doe/name /author /head entry titleAtom Powered Robots Run Amok/title id href=vemmi://example.org/2003/32397/ updated2003-12-13T18:30:02Z/updated /entry /Feed This exercise should be done with a much larger example, to see what bugs remain in the current spec. The above exercise show the following bugs: - Feed should probably be capitalized as above - id should take an href as above instead of the example from the spec idvemmi://example.org/2003/32397/id Things like that are really simple cleaning up exercises, that would in no way change the functionality of Atom, but allow all of the RSS1.0 folk with their experience to declare Atom as their successor format, and Atom to come clean on its extensibility requirement from the charter. The nice thing is that this is done whilst taking on board all the criticism from the RSS2.0 folk. It looks to me that Atom is close to ending the RSS wars. Time to smoke the peace pipe. Henry Story On 18 Dec 2004, at 18:21, Henry Story wrote: Feed head titleExample Feed/title link href=http://example.org// updated2003-12-13T18:30:02Z/updated author rdf:ParseType=Resource rdf:type rdf:resource=atom;Person/ nameJohn Doe/name /author /head entry titleAtom Powered Robots Run Amok/title id href=vemmi://example.org/2003/32397/ updated2003-12-13T18:30:02Z/updated /entry /Feed
