Re: PaceRepeatIdInDocument solution
Bob Wyman wrote: Given that history shows that publishing repeated ids has never bothered anyone enough to cause them to complain, we should permit this benign practice to continue. I have exactly the opposite experience. I have people who have thanked me for noticing that they have repeated ids as it indicated an error in their software. - Sam Ruby
Re: PaceRepeatIdInDocument solution
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? 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. Graham
Re: PaceRepeatIdInDocument solution
On 20/2/05 4:34 PM, Graham [EMAIL PROTECTED] wrote: That's not what I meant. I opposed atom:modified because this use case wasn't on the table then. I oppose multiple ids partly because we don't have atom:modified. You can't have one without the other. if this use case was on the table back then, and you were to consider the question in that light, where would you stand? (actually, we could have atom:modified while still outlawing multiple id's, but you are right that atom:modified is required to disambiguate if multiple id's are allowed.) My real problem with atom:modified is that it's unnecessarily tied to the Last Modification Date semantic, when it would work just as well for this purpose if it weren't. We just need a date with the constraint date(a)date(b) whenever entry instance a is older than entry instance b. This would make it easier to generate in various scenarios, and sidestep the problem of defining what a modification is. heh -- one way to then generate to fit your requirements would be atom:modified := atom:published + sequential-number that is, increment the atom:modified by one second for every version. Semantically, it would work ... for comparing two instances of one entry. It wouldn't work for establishing if an entry was modified before or after [some event moment] (eg. close of the stock exchange). As to defining modification ... I was writing spec text which attempted just that ... I was working towards the idea that any changes in values of atom:entry elements, other than serialisation (including character encoding and element order), and ignoring any changes in referenced resources. Nonsense. That's like arguing that http agents should only support those mime-types which were already defined oh so many years ago. No software currently exists that can possibly be expecting application/foo, but that doesn't mean application/foo is an illegal mime-type. No, since the HTTP spec says that any mime type is possible, whereas the Atom spec says ids are universally unique. If it's wrong to then think you won't find the same id twice in the same document, the spec needs to say so. My apologies: I was making an analogy, not providing an example. As such, ignore the specifics of the analogy. I should have just written Spec FOO is silent on X, therefore X is verboten. Which is a nonsense position. e.
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
About logical clocks in atom:modified: --On February 21, 2005 3:30:13 AM +1100 Eric Scheid [EMAIL PROTECTED] wrote: Semantically, it would work ... for comparing two instances of one entry. It wouldn't work for establishing if an entry was modified before or after [some event moment] (eg. close of the stock exchange). Establishing sequences of events is rather tricky. See Leslie Lamport's Time, Clocks, and the Ordering of Events in Distributed Systems for how to do it with logical clocks. The core part of the paper is short, maybe five pages, and definitely worth reading if you care about this stuff. http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf Synchronized clocks make this simpler. If Atom depends on comparing timestamps from different servers, then synchronized clocks are a SHOULD. See the text in PaceCaching for an example. Synchronized clocks are already a SHOULD for HTTP. wunder -- Walter Underwood Principal Architect, Verity
Re: PaceRepeatIdInDocument solution
On 20 Feb 2005, at 4:30 pm, Eric Scheid wrote: if this use case was on the table back then, and you were to consider the question in that light, where would you stand? I like the model where the feed content is approximately The current version of the latest entries. I don't think anything else makes much sense, least of all Various states past and present of various entries (some assembly required). heh -- one way to then generate to fit your requirements would be My idea would be that the originating server would simply stamp entries with the current time during feed generation, so if they get mixed up in transit by third parties or caches the later version would still be known. Note the originating server doesn't have to store or keep track of anything. As to defining modification ... I was writing spec text which attempted just that ... I was working towards the idea that any changes in values of atom:entry elements, other than serialisation (including character encoding and element order), and ignoring any changes in referenced resources. But that gets complicated to generate cleanly. When you edit your feed template you need to do something like: if (entry modification date date template was edited) print date template was edited else print entry modification date Generating a last modification date according to someone else's idea of modification is not pretty. My apologies: I was making an analogy, not providing an example. As such, ignore the specifics of the analogy. I should have just written Spec FOO is silent on X, therefore X is verboten. Which is a nonsense position. I wouldn't define the phrase universally unique as Atom being silent. It is massively open to interpretation since the literal meaning is nonsense, and I suppose conveying no useful information could be interpreted as silence. Graham
RE: PaceRepeatIdInDocument solution
Graham wrote: My idea would be that the originating server would simply stamp entries with the current time during feed generation, so if they get mixed up in transit by third parties or caches the later version would still be known. Note the originating server doesn't have to store or keep track of anything. You propose timestamps, yet you oppose atom:modified -- which was intended to provide precisely the timestamps you suggest. Or, is there something I am missing? (atom:modified was entry-specific but you seem to be suggesting a feed-global timestamp...) Is the problem in your comment that the originating server doesn't have to store or keep track of anything? Does this imply that your timestamp is really just the atom:updated of the feed and would change every time that the feed was updated? If this is the case, should we reword the definition of atom:updated to say that when it is used as feed metadata, it MUST be updated every time the feed is changed in ANY way? Should the significant change words only apply to atom:updated in entries? (Note: Since the feed's atom:updated is an element of Head, this implies that if HeadInEntry stands, the feed's atom:updated would or could be in the entry.) If your timestamp is really the same as the feed's atom:updated, then what is the impact of your proposal on signatures? Would all individual entries in a feed need to be re-signed every time any change was made to the feed such as inserting a new entry? Would this be the case even if the change did not otherwise modify the signed entry? Does your timestamp proposal imply that an entry which appeared in multiple feeds would have a different timestamp in each feed it appeared? (Note: That would have the odd effect of tending to make error-prone copies consistently appear to be the 'last modifications.' One tends to write to the main feed first and then later to category feeds... Copies will generally have timestamps later than the originals.) Generating a last modification date according to someone else's idea of modification is not pretty. Yes! This is the problem that an intermediary in the channel faces. The intermediary (a proxy, retrospective search engine, prospective matching engine, etc.) needs to know which entry is the most recent modification. However, Atom provides no mechanism by which the last modification can be identified without heuristics. (atom:updated only tells you the time of the last significant modification but that leaves you unable to determine which of various alternative insignificant modifications should be passed on by the intermediary. Without help from the Atom format, the best an intermediary can do is keep track of date_entry_was_found. However, this can cause problems since entries can exist in multiple feeds. Thus, the order in which the feeds are read can cause old entries to over-write newer ones. bob wyman
Author tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi guys, I looked at the mail archive. It's a shame it doesn't have a search facility on the web page. In any case, I am writing some Atom parsing libraries for Java, as I found the existing ones to be old and usually only partial implementations. I'm basically where I need to be, except I could use some additional clarity on the Author element. If I look at the Feedburder feed for my blog (feeds.feedburner.com/Melbournephilosopher) I notice that the author element is author ~name MelbournePhilosopher /name /author while the spec makes no mention of this. Cheers, - -Tennessee -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCGYADFp/Peux6TnIRArPfAJ9gmHZQMhcdNV80soSulorjtKnqvACfSJvR I9vBueXuSxtihUIjIMZNCA0= =GIux -END PGP SIGNATURE-
Re: Author tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Clarification: The spec makes no mention of the sub-element name. It looks like the author tag is the leaf node, and should contain only text. | Hi guys, | | I looked at the mail archive. It's a shame it doesn't have a search | facility on the web page. In any case, I am writing some Atom | parsing libraries for Java, as I found the existing ones to be old | and usually only partial implementations. I'm basically where I | need to be, except I could use some additional clarity on the | Author element. If I look at the Feedburder feed for my blog | (feeds.feedburner.com/Melbournephilosopher) I notice that the | author element is | | author ~name MelbournePhilosopher /name /author | | while the spec makes no mention of this. | | Cheers, -Tennessee -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCGYZGFp/Peux6TnIRAq7lAJ4iwgjgx6AOqOX/Xzv6xEm/2nIrSwCePqoP C+F5+lbgzPM2RsYPCp8eTHM= =+Xsb -END PGP SIGNATURE-
Re: Author tag
Tennessee Leeuwenburg wrote: author ~name MelbournePhilosopher /name /author Current draft specification: http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-05.txt atom:author element is defined on page 20 atom:author uses the Person Construct. So have a look at Section 3.2 Person Constructs page 9.
