Re: PaceAllowDuplicateIdsWithModified
On 18/5/05 7:41 PM, Graham [EMAIL PROTECTED] wrote: Not so very long ago you suggested that aggregators look at the content to determine if it's changed. If it's good enough for aggregators, it's good enough for publishers (actually better than good enough since the publisher would be able to do the test before other transformations occur, thus eliminating some false positives). But if the publisher does that, atom:modified is going to end up being the date the atom-generating program is run rather than the date the modification happened. You may argue that functionally this doesn't matter, and you'd be right. You'd also be admitting that the absolute date is not important, as long as the dates are in the right order - aka atom:version. not quite. I agree the absolute date of modification is open to philosophical argument (eg. an author retrieves an entry into their editor, changes some bit, goes off for 5 minutes to answer the phone, comes back and presses the submit button ... what is the true date of modification now?) The absolute or true date of modification isn't the quality I'm interested in though. What I am interested in is having one such timestamp for any given modified content. Not multiple timestamps for the exact same content, which is what atom:version sloppily allows. e.
Re: Consensus call on last raft of issues
Tim Bray wrote: On May 18, 2005, at 6:19 PM, Sam Ruby wrote: Isn't that redundant? From PaceOptionalSummary: Yup. Think we got that covered. -Tim Off list, Robert pointed out to me that that the spec text I cited didn't cover empty summaries. He's right. - Sam Ruby
PaceTextShouldBeProvided and accessibility - was Re: Consensus call on last raft of issues
Tim Bray wrote: PaceTextShouldBeProvided +1 from Ruby, explicit -1's from Sayre and de hÓra. However, taking this and PaceOptionalSummary together, it seems clear that the WG generally believes the following: - Title-only feeds are OK for data where that's really all you have. - Failing to provide summaries when they could potentially exist is regrettable and should be discouraged. - There are certain classes of software which will not be able to make use of content-light feeds, for example full-text indexers. - It is not acceptable for software to fail (note fail, as opposed to not make full use of) just because the summary is missing. There is lack of consensus in the WG as to whether RFC2119 SHOULD is an appropriate level of language to use in encouraging the provision of summaries. Conclusion: This Pace is rejected. However, the editors are directed to include the following text in 4.2.13: Experience teaches that feeds which contain textual content are in general more useful than those which do not. There are certain classes of application, for example full-text indexers, which will be unable to make effective use of entries which do not contain text in either atom:summary or atom:content. Feed producers should be aware of these issues and are encouraged to include a meaningful atom:summary in entries lacking atom:content wherever possible. However, the absence of atom:summary is not an error and software MUST NOT fail to function correctly as a consequence of such an absence. I'd urge that the wording here should also include accessibility concerns, especially to encourage accessible alternatives to to be adopted when the content is known to be inaccessible - e.g. images, sound files, movies, flash. HTML for instance has a number of accessible alternatives to inaccessible constructs - images have a src attribute, flash and embedded movies allow the child of the object element to contain accessible alternatives to the content. In the situation where an Atom Entry is presented to a human being, if one of those representations is HTML, e.g. (representing the non-textual content in HTML as an object element with a @src reference), then without the presence of accessible alternatives to inaccessible media, its going to be problematical, and downright impossible to generate accessible content for the user. May I suggest the following addition: Where an Atom Entry with non-textual content is created for use by people - either in their browsers or screen readers, it must also include an equivalent accessible alternative. From the XML Accessibility Guidelines, Guideline 1.1 url:http://www.w3.org/TR/xag#g1_0 1.1 Provide a mechanism to explicitly associate alternatives for content or content fragments. Authors using the elements/attributes in your language must have the ability to provide alternatives for any content, be it images, movies, songs, running text, whatever. We've got the mechanism - e.g. the summary and link elements of an Atom Entry, we need to highlight these uses in 4.2.13. Thanks, Mike
Re: Consensus call on last raft of issues
Graham wrote: On 18 May 2005, at 9:36 pm, Robert Sayre wrote: atom:entry elements are advised to contain ... a non-empty atom:summary element when the entry contains no atom:content element I'd like us to advise including an atom:summary when atom:content is binary (or for that matter, any non-text/html/xhtml type) +1 (From an accessibility perspective)
Re: PaceTextShouldBeProvided and accessibility - was Re: Consensus call on last raft of issues
On 5/19/05, Isofarro [EMAIL PROTECTED] wrote: I'd urge that the wording here should also include accessibility concerns, especially to encourage accessible alternatives to to be adopted when the content is known to be inaccessible - e.g. images, sound files, movies, flash. HTML for instance has a number of accessible alternatives to inaccessible constructs - images have a src attribute, flash and embedded movies allow the child of the object element to contain accessible alternatives to the content. Presumably you mean images have an alt attribute, but otherwise +1. Note that HTML 4 and beyond *require* an alt attribute for images, but does not similarly require non-script alternatives to script elements. Nor does it explicitly require accessible alternatives to embedded media such as Flash or video; the mechanism is present and encouraged, but ultimately optional. Since the last time this came up on the list, I have relaxed my position, and I am now fine with defining a feed format that encourages, but ultimately does not require, accessible content. Note that inaccessible content is A Bad Thing(tm) and in some contexts content producers will be legally or contractually obligated to provide it, but I will not go so far as to say that the format itself should force you to provide it. The format spec is the proper place to STRONGLY RECOMMEND that you provide accessible alternatives to inaccessible context (and we already have sufficient mechanisms to provide such alternatives), but I will no longer go so far as to call it a MUST. -- Cheers, -Mark
Compulsory feed ID?
On May 18, 2005, at 9:11 AM, Sam Ruby wrote: There seemed to be consensus that feeds needed something to identify them. What there wasn't consensus on is which element should be that identifier. The solution selected was to make none of the identifiers required - something I don't think has much support, and furthermore creates problems with the ability to cite a source. Paul and I talked this over, and while we're not sure (the email trail was confusing) Sam may be right; so let's find out. Note that it seems pretty clear that the cost of requiring atom:id is nearly zero, since anyone who's generating Atom has to have an ID generator around for entries. So, let's find out if Sam is right: co-chair-mode We suggest that there may be WG consensus in favor of changing the format spec to make atom:id a required child of atom:feed. (Text not provided, we trust the editors to figure out the correct way to say this). Please indicate agreement or disagreement with this proposition in the next day or two. /co-chair-mode
Non-empty elements
Some applications may choose to require a minimum amount of inline text or (X)HTML data to function reliably and predictably. For that reason, atom:entry elements are advised to contain a non-empty atom:title element, a non-empty atom:summary element when the entry contains no atom:content element, and a non-empty atom:content element when that element is present. We observe that the paragraph above is getting support from the WG members who have been most engaged in this area of the discussion. Rephrasing slightly because I don't believe that XML elements are very responsive to advice. As an example freak, I'd also like to keep the concrete example of a full-text indexer from the consensus call. Thus, co-chair-mode Paul and I consider that the following text has consensus support of the WG and the editors are directed to include it in the format draft (editorial judgment call on where to insert): Some applications (one example is full-text indexers) require a minimum amount of text or (X)HTML to function reliably and predictably. For that reason, it is advisable that each atom:entry element contain a non-empty atom:title element, a non-empty atom:summary element when the entry contains no atom:content element, and a non-empty atom:content element when that element is present. /co-chair-mode -Tim
Re: Non-empty elements
On 5/19/05, Tim Bray [EMAIL PROTECTED] wrote: co-chair-mode Paul and I consider that the following text has consensus support of the WG and the editors are directed to include it in the format draft (editorial judgment call on where to insert): Some applications (one example is full-text indexers) require a minimum amount of text or (X)HTML to function reliably and predictably. For that reason, it is advisable that each atom:entry element contain a non-empty atom:title element, a non-empty atom:summary element when the entry contains no atom:content element, and a non-empty atom:content element when that element is present. /co-chair-mode Is this text intended to replace the paragraph the editors were previously directed to insert? Robert Sayre
multiple ids
--- The editors are directed to modify the phrase which starts If multiple atom:entry elements... as follows: 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. --- We don't use the word 'software' in the draft. The editors request replacement text. Robert Sayre
remote content?
I don't think we ever resolved this last call issue. http://www.imc.org/atom-syntax/mail-archive/msg14383.html Tim Bray wrote: OK, WG, what do you think? I have long supported the SHOULD here, but I can't help observing that a lot of different parties have questioned it, I'm not 100% sure it really has consensus support, even rough. Rob John's alternative, as outlined above, seems like a fair trade-off that would better reflect the community consensus and not really harm interoperability. Anybody want to disagree? Robert Sayre
Re: Compulsory feed ID?
Tim Bray wrote: On May 18, 2005, at 9:11 AM, Sam Ruby wrote: There seemed to be consensus that feeds needed something to identify them. What there wasn't consensus on is which element should be that identifier. The solution selected was to make none of the identifiers required - something I don't think has much support, and furthermore creates problems with the ability to cite a source. Paul and I talked this over, and while we're not sure (the email trail was confusing) Sam may be right; so let's find out. Note that it seems pretty clear that the cost of requiring atom:id is nearly zero, since anyone who's generating Atom has to have an ID generator around for entries. So, let's find out if Sam is right: Permit me to provide some more background. I *think* that there is some desire that if the SAME entry appears in multiple places (say, TheServerSide, Java.net, Artima, etc.) that it not appear multiple times. This specific example was called out here: http://www.tbray.org/ongoing/When/200x/2005/04/03/Atom-Now#p-1 I appologize for referencing something outside of the mailing list, and if the item I cited does not represent the consensus of the working group, then the following text should be removed from PaceDuplicateIDs: If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they represent the same entry - - - If, however, this above is what we desire (and I certainly support it), let's see what Bob's objection was: http://www.imc.org/atom-syntax/mail-archive/msg14470.html In that, he said: The problem is, once again, that prohibiting duplicate ids provides an easy to use attack vector for those wishing to effectively erase entries written by another author. Now, lets take a look again at that text from PaceDuplicateIDs: If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they represent the same entry. It seems to me that this does not solve the problem that Bob described. More specifically, if pubsub were to republish data from TheServerSide, Artima, or other places, then the erasure that Bob fears would come to pass. What's most puzzling is that it appears that PaceDuplicate IDs was specifically written in response to Bob's concerns: http://www.imc.org/atom-syntax/mail-archive/msg14731.html What is missing in all this is the following, again from Bob's original statement of the problem: Graham Park has proposed that we loosen the existing language to permit duplicate ids in the case where the entries have atom:source elements which identify different URIs in self links. I support this compromise and believe it should be supported by the WG and incorporated into the Atom Draft. This proposal seemed to have enjoyed some support, yet it did not seem to have made it into the current draft, despite being crucial to the solving the issue that PaceDuplicateIDs was designed to address. However, for it to work, the re-aggregator would need to have access to a self link, which is not required by the current draft. What should we do? One way to solve this is to require id *and* update Graham's original proposal accordingly, *and* incorporate it into the next (and presumably final draft). - - - That's what I meant by There is a danger of looking at changes in isolation.: http://www.imc.org/atom-syntax/mail-archive/msg15292.html Of course, breaking any link in my complicated chain of logic above would cause the whole argument to collapse, which would be fine with me. Does anybody see something that I am missing? - Sam Ruby
Re: Compulsory feed ID?
On 5/19/05, Sam Ruby [EMAIL PROTECTED] wrote: Of course, breaking any link in my complicated chain of logic above would cause the whole argument to collapse, which would be fine with me. Maybe the requirement is useless. 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. MUST treat them as such isn't particularly meaningful, and two atom:entry elements occuring anywhere are supposed to be describing the same entry. When I get CCed on an atom-syntax message, some of my email programs show two messages, and some show one. It's a security/annoyance trade-off, and I don't see why the format should be making that decision. Robert Sayre
Re: Compulsory feed ID?
/ Sam Ruby [EMAIL PROTECTED] was heard to say: | What should we do? One way to solve this is to require id *and* update | Graham's original proposal accordingly, *and* incorporate it into the next | (and presumably final draft). | | - - - | | That's what I meant by There is a danger of looking at changes in | isolation.: | |http://www.imc.org/atom-syntax/mail-archive/msg15292.html | | Of course, breaking any link in my complicated chain of logic above would | cause the whole argument to collapse, which would be fine with me. | | Does anybody see something that I am missing? I have to say that the DoS issue hadn't occurred to me before Bob raised it and I've been a bit depressed about it ever since it came up. Is there really anything that we can do here, short of providing a mechanism for signing entries and telling aggregators that a duplicate is an entry with the same id and the same signature? Seems to me if I'm unscrupulous enough to attempt DoS, I can fake all of the required parameters. /me shrugs Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | Happiness is a how, not a what; a http://nwalsh.com/| talent, not an object.--Herman Hesse pgpm9pkr2fBDr.pgp Description: PGP signature
Re: Non-empty elements
/ Tim Bray [EMAIL PROTECTED] was heard to say: | co-chair-mode | Paul and I consider that the following text has consensus support of the WG | and the editors are directed to include it in the format draft (editorial | judgment call on where to insert): | | Some applications (one example is full-text indexers) require a minimum | amount of text or (X)HTML to function reliably and predictably. For that | reason, it is advisable that each atom:entry element contain a non-empty | atom:title element, a non-empty atom:summary element when the entry | contains no atom:content element, and a non-empty atom:content element when | that element is present. | /co-chair-mode +1 Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | The first step towards madness is to http://nwalsh.com/| think oneself wise.--Fernando De Rojas pgpgw9fXyDGCW.pgp Description: PGP signature
Re: Compulsory feed ID?
On 5/19/05, Sam Ruby [EMAIL PROTECTED] wrote: Graham Park has proposed that we loosen the existing language to permit duplicate ids in the case where the entries have atom:source elements which identify different URI's in self links. I support this compromise and believe it should be supported by the WG and incorporated into the Atom Draft. I believe it makes sense to give the notional atoms (entries) individual identifiers which will be preserved globally, irrespective of the source, irrespective of where the entries are found - so yes, duplicate IDs in a feed seem an acceptable scenario. I don't personally care how it's done, but a reference back from the feed document to the URI from whence it is begetted is pretty essential for the easier one-click subscription strategies, and should come in handy later for aggregate-republish processing. I think a reference back to the source (original better, intermediate better than nothing) is also desirable to help reduce duplicate posts appearing in any end-of-chain UI. Take this scenario - two entries identical in every respect *except* for their ID. Any resource on the Web may have any number of different URIs, which suggests any entry might /potentially/ have any number of IDs. Should the two entries be allowed in the same feed? If you change the name of an entry, do you change its nature? Sorry, slipping, it's a bit late here - scratch the philosophy, ;-) Basically I reckon duplicate IDs in a feed are ok - leave it to the (final or intermediate) consumer to filter out if required according to local rules/heuristics. Cheers, Danny. -- http://dannyayers.com
Re: Non-empty elements
Rephrasing slightly... + 1 -- Roger Benningfield
Re: Compulsory feed ID?
On 19 May 2005, at 9:38 pm, Sam Ruby wrote: What should we do? One way to solve this is to require id *and* update Graham's original proposal accordingly, *and* incorporate it into the next (and presumably final draft). The original proposal actually relied on ids: http://www.intertwingly.net/wiki/pie/PaceDuplicateIDWithSource Just to be clear, the idea wasn't that an entry would have a concatenated entry:id-source:id as its identifier. The entry:id would still be primary, its just multiple versions received from different sources could be represented. If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they represent the same entry. It seems to me that this does not solve the problem that Bob described. More specifically, if pubsub were to republish data from TheServerSide, Artima, or other places, then the erasure that Bob fears would come to pass. I don't really believe this to be so. An aggregator can treat them as the same entry without having one overwrite the other. It can easily present to the user Here's the version from Site A and Here's the version from Site B. That was kind of the idea of PaceDuplicateIDWithSource. Of course, the atom:source element is as fakeable as the entry's id. The only reliable origin is the URI it was directly fetched from. Oh, and compulsory feed:ids are fine with me. Certainly better than the hybrid proposals. Graham
Re: Compulsory feed ID?
On 19/5/05 10:41 PM, Tim Bray [EMAIL PROTECTED] wrote: We suggest that there may be WG consensus in favor of changing the format spec to make atom:id a required child of atom:feed. (Text not provided, we trust the editors to figure out the correct way to say this). Please indicate agreement or disagreement with this proposition in the next day or two. wth, +1
Re: Compulsory feed ID?
On Thursday, May 19, 2005, at 06:41 AM, Tim Bray wrote: We suggest that there may be WG consensus in favor of changing the format spec to make atom:id a required child of atom:feed. (Text not provided, we trust the editors to figure out the correct way to say this). Please indicate agreement or disagreement with this proposition in the next day or two. Since I've already expressed my opinions on this issue, I'll be brief just to register my opinion in this thread. I don't think atom:id is the most useful possible identifier, so this isn't my first choice. But if we can't agree to use a better one, it'll be better than nothing.
Re: Non-empty elements
On 19 May 2005, at 2:07 pm, Tim Bray wrote: Some applications (one example is full-text indexers) require a minimum amount of text or (X)HTML to function reliably and predictably. For that reason, it is advisable that each atom:entry element contain a non-empty atom:title element, a non-empty atom:summary element when the entry contains no atom:content element, and a non-empty atom:content element when that element is present. I find the conflation of presence and emptiness a little opaque. I'd rather the text said that, in general, when any of these elements are present they shouldn't be empty. The other part of this text, that summary be present when content isn't, can then be separated out for the sake of clarity. Otherwise, it's fine. Graham
Re: multiple atom:author elements?
On Thursday, May 19, 2005, at 09:41 PM, Eric Scheid wrote: I see this as a problem... 4.1.2 The atom:entry Element * atom:entry elements MUST contain exactly one atom:author element, unless the atom:entry contains an atom:source element which contains an atom:author element, or, in an Atom Feed Document, the atom:feed element contains an atom:author element itself. * atom:entry elements MUST NOT contain more than one atom:author element. Science Journals are just one example of feeds which require being able to specify multiple authors per entry. I have Library clients who want to make their indexing efforts available in XML form - currently I can recommend RSS 1.0, but I would like to be able to recommend Atom 1.0 when it becomes available. With a one-author-per-article restriction this would be impossible. Shall I write a Pace? If we do allow multiple authors, we might want to put a warning in that consuming applications MAY ignore some of them if more than one is supplied. As long as we do that, and perhaps even if not, I'd be in favor of allowing more than one.
Re: multiple atom:author elements?
On 20/5/05 2:10 PM, Antone Roundy [EMAIL PROTECTED] wrote: If we do allow multiple authors, we might want to put a warning in that consuming applications MAY ignore some of them if more than one is supplied. As long as we do that, and perhaps even if not, I'd be in favor of allowing more than one. I'm happy with that - the market will sort out what is an acceptable level of support. I really don't want to see this in an Atom feed: authornameRaggett, D, Hors, A, and I Jacobs/name/author (perfectly acceptable for display, but not for data) e.
