Re: PaceContentAndSummaryDistinct2 posted
-1 This is insufficiently explicit. We need to make implementers stop and think which element to use, rather than just copy/pasting their RSS generation code into both. The requirement the summary and content be different would do that; stating it unequivocally as in PaceContentAndSummaryDistinct would also. PaceContentAndSummaryDistinct2 requires them to grasp both definitions, compare them and realise that we mean them to be different from a close textual reading. On May 15, 2005, at 3:23 PM, Graham wrote: http://www.intertwingly.net/wiki/pie/PaceContentAndSummaryDistinct2 == Abstract == Codify the intended use of content and summary clearly, but more subtly than the original PaceContentAndSummaryDistinct. == Status == Newly posted == Rationale == PaceContentAndSummaryDistinct correctly point out the current definitions are too vague: The atom:summary element is a Text construct that conveys a short summary, abstract or excerpt of an entry. The atom:content element either contains or links to the content of the entry. The aim of this proposal is to use similar language in both definitions so they can be more easily compared, especially re: the best location of truncated content. == Proposal == In 4.2.13, replace: The atom:summary element is a Text construct that conveys a short summary, abstract or excerpt of an entry. with: The atom:summary element is a Text construct that conveys a short summary, abstract or excerpt (such as truncated content) of an entry. In 4.1.3 replace: The atom:content element either contains or links to the content of the entry with: The atom:content element either contains or links to the full content of the entry == Impacts == Alternate to PaceContentAndSummaryDistinct == Notes == The new wording of 4.2.13 is a bit awkward, but since truncated content is by far the most common form of excerpt, its probably worth mentioning specifically.
Re: nit: spaces in [EMAIL PROTECTED]
-1 This is a gratuitous variation from exisiting practice. As you may have noted from previous work, allowing multiple rel values enables a great deal of useful flexibility in HTML. On May 12, 2005, at 10:32 AM, Graham wrote: On 12 May 2005, at 5:23 pm, Eric Scheid wrote: This is confusingly different from HTML's [EMAIL PROTECTED] and should be fixed. I believe the intention is that only one value is allowed, and any whitespace included is part of the name of the rel value. Perhaps this should be noted in the spec. Or are you suggesting we adopt the HTML method? Graham
Re: extensions -- Atom NS and unprefixed attributes
Robert Sayre wrote: On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote: Too terse - I don't understand why you're asking this. But if you really think that we allow everything we don't ban, we should say that somewhere in the spec. hmm. I could write that Pace if you want, but maybe it would be more productive to explain why you find my interpretation psychotic. Because it's an interpretation that cares not for others. I could ask if you could maybe explain why that was more a productive direction, but isn't this getting silly now? Maybe you could point to some spec text to back up your opinion. Postel's law. MarkN seems to think its only this or other IETF working groups that can extend the Atom namespace. I don't see anything in the spec about that. Let's agree I made an error of judgement in my characterisation and call your interpretation something neutral instead - interpretation-x. As I've withdrawn 'psychotic' I think it's reasonable to say we can stop quibbling and move on. The point remains - if you think interpretation-x is valid way of systematically evaluating the spec, then there is room to discuss whether we should make mention of it. Will you address now whether we should mention or approve that interpretation in the spec? cheers Bill
Re: PaceOtherVocabularies
On May 17, 2005, at 01:35, Robert Sayre wrote: Markup from other vocabularies (foreign markup) can be used in an Atom document, but MUST be namespace-qualified and in a namespace other than Atom's. Surely attributes on extension elements don't need to be ns-qualified? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Change Control (was: extensions -- Atom NS and unprefixed attributes)
On 5/17/05, Bill de hÓra [EMAIL PROTECTED] wrote: Maybe you could point to some spec text to back up your opinion. Postel's law. My concern is about change control, not processing. We have an elaborate system for controlling additions to the list of link relations. Why aren't we more explicit with element names in the Atom namespace? I don't particularly care which strategy we settle on, but it's important to be clear. Do we have a situation similar to HTTP headers and methods, where you can extend it as needed, but you had better 'coordinate' if you want to make sure everyone interprets it the same way? That's fine. Or do we have an IETF-administered registry? If we do settle on the looser approach for elements, I suggest we drop the link registry and go with the space-separated lists allowed by HTML. Robert Sayre
Re: Change Control (was: extensions -- Atom NS and unprefixed attributes)
On Tuesday, May 17, 2005, at 08:22 AM, Robert Sayre wrote: Do we have a situation similar to HTTP headers and methods, where you can extend it as needed, but you had better 'coordinate' if you want to make sure everyone interprets it the same way? That's fine. Or do we have an IETF-administered registry? XML namespaces create a middle road between the two--anyone can add elements to an XML document without fear of naming collisions because XML has a built-in coordination method. What possible advantage would there be to allowing just anyone to add elements to Atom's namespace, or any other namespace, for that matter? I can't think of any. In my opinion, alteration of a namespace by anyone other than the entity that created it, or someone authorized by its creator, would completely violate the nature of namespaces. I wouldn't think it would be necessary to spell that out explicitly, but since obviously not everyone agrees, we may as well do so. So I'd say we have an IETF-administered registry.
Re: PaceOtherVocabularies
On 17 May 2005, at 2:45 pm, Henri Sivonen wrote: Markup from other vocabularies (foreign markup) can be used in an Atom document, but MUST be namespace-qualified and in a namespace other than Atom's. Surely attributes on extension elements don't need to be ns-qualified? Yes, although extension attributes on Atom elements do need to be. Graham
Re: Change Control (was: extensions -- Atom NS and unprefixed attributes)
On 17 May 2005, at 3:47 pm, Antone Roundy wrote: XML namespaces create a middle road between the two--anyone can add elements to an XML document without fear of naming collisions because XML has a built-in coordination method. What possible advantage would there be to allowing just anyone to add elements to Atom's namespace, or any other namespace, for that matter? I can't think of any. In my opinion, alteration of a namespace by anyone other than the entity that created it, or someone authorized by its creator, would completely violate the nature of namespaces. I wouldn't think it would be necessary to spell that out explicitly, but since obviously not everyone agrees, we may as well do so. So I'd say we have an IETF-administered registry. Put me in the Only those elements defined in IETF RFCs may use the Atom namespace column. Graham
Re: Change Control (was: extensions -- Atom NS and unprefixed attributes)
On 18/5/05 1:57 AM, Graham [EMAIL PROTECTED] wrote: Put me in the Only those elements defined in IETF RFCs may use the Atom namespace column. +1
Re: PaceAllowDuplicateIdsWithModified
Monday, May 16, 2005, 5:39:17 PM, Graham wrote: On 16 May 2005, at 5:16 pm, Eric Scheid wrote: if you want to sort by updated or published, but not for most recently changed (even if not 'significantly') Well yes. So? I consider atom:modified to be unfeasible anyway for all sorts of reasons, so we're not losing any capability here. Can you explain some? I don't see atom:version would be more feasible. atom:version doesn't support some cases that atom:modified does, and it doesn't really seem easier to explain in the spec or implement. Are you thinking of some scenarios where a publisher wouldn't be able to produce a modified date, but would be able to produce a version? - or do you mean it wouldn't be feasible for other non-technical reasons? -- Dave
Re: PaceAllowDuplicateIdsWithModified
Monday, May 16, 2005, 12:07:23 PM, Sam Ruby wrote: 3) Perhaps version/modified need not be mandatory except in those instances where entries with duplicate ids are present in a feed? If we want to support the cases of aggregating multiple feeds and of full archiving (other than by the publisher), then it needs to be mandatory doesn't it? The subscriber/archiver may be a different entity than the publisher; if the publisher doesn't provide modified/version, then what is the subscriber supposed to do? -- Dave
Re: PaceAllowDuplicateIdsWithModified
On 18 May 2005, at 1:03 am, David Powell wrote: Can you explain some? I don't see atom:version would be more feasible. atom:version doesn't support some cases that atom:modified does, and it doesn't really seem easier to explain in the spec or implement. The first problem is that not all systems track a modified date. If you're obtaining entries using an API on a closed system, and the system doesn't supply a modified date for whatever data you're syndicating, you're screwed. The second problem is that modification is an incredibly hard thing to pin down, eg: - I modify my atom-generating script to change which optional elements are included. Does the modification date change? - I modify my atom-generating script to change the order elements appear in. Does the modification date change? - I change the location of my entries, and therefore the atom:link element values. Does the modification date change? - I change the location of my entries, and therefore the xml:base attribute on a parent element. Does the modification date change? - I change the email address of an entry's author, but not the entry itself. Does the modification date change? etc etc Don't bother answering yes or no to any of these here. The point is that even if you do pin down exactly which count as modifications, you have to demonstrate it can easily be implemented and tracked exactly that way on the average CMS (Note adding new columns to the database may not be possible). Graham
Consensus call on last raft of issues
On behalf of Paul and myself. Atom issues list: http://www.intertwingly.net/wiki/pie/AtomPubIssuesList The volume of correspondence was unfortunately high for an IETF Last Call that came after a Working Group Last call. It is quite possible, as always, that the co-chairs have mis-read the consensus of the group on one or more issues; in which case please push back. We can work on this as long as is needed, and given the passion (and, in some cases, intransigence) we have seen so far, we do not expect to reach unanimity. When you respond to any of these readings of consensus, please do so with the intention of helping the chairs figure out whether or not we have determined consensus, not just to state an opinion one way or another. Thanks! PaceAllowDuplicateIDs We see a bunch of +1's with an unambiguous -1 only from Duerst. Sayre was negative (2005/05/05 6:41 AM) but didn't record a -1. Parks has been mostly against, but a close reading of his posts make it clear that his issue is in large part with atom:updated, he remains convinced that readers desire notification of every change however minor and are unwilling to trust publishers' opinions as expressed in atom:updated. He could live with this Pace if we re-introduced atom:modified or inserted wording in the spec emphasizing that if multiple entries with the same atom:id appear in a feed, software must treat them as XXX of the same entry; there was lively debate as to whether XXX was versions, instantiations, or representations. Conclusion: The Pace is accepted. 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. PaceAlternateLinkWeakening Only one +1, not good enough, it fails. PaceBriefExample Two +1's, seems awfully uncontroversial, verging on editorial, accepted unless someone shouts. === PaceCaching Multiple -1's, it fails. = PaceCoConstraintsAreBad Obsoleted. Rejected. PaceContentAndSummaryDistinct This was modified in the course of debate. It can't be accepted because the +1's (and -1's too) were referring to multiple different wordings and there were three pretty strong -1's. Conclusion: The editors are asked to strengthen the language in the draft that emphasizes the difference in intended purpose between content and summary. This can be done by adding a sentence to 4.2.13 that says The text in atom:summary should not be identical to the text in atom:content or identical to the text in atom:title. However, this might have gained consensus if it were stable. If a bunch of voices get behind a single version in the next 72 hours and win the hearts of the -1's, the door is open. = PaceContentAndSummaryDistinct2 One each +1 and -1, hardly consensus. Rejected. == PaceDuplicateIDWithModified A handful of +1's, one -1. The consensus of the group against atom:modified months and months ago was quite strong and this is not enough momentum to accomplish such a major policy reversal. Rejected. === PaceDuplicateIDWithSource PaceDuplicateIDWithSource2 A couple of -1's, no support, rejected. === PaceEntryState Rejected, no support. = PaceExplainDuplicateIDs Only one +1 but once again, uncontroversial, mostly editorial, accepted unless someone squawks. PaceFeedIdOrAlternate No postings. Rejected. = PaceFeedIdOrSelf Reworded in progress, too many -1's, rejected. = PaceNoAlternativeForFeed Only one +1 from its author, it fails. = PaceOptionalFeedLink Lots of +1's, moderate objections from Ruby, accepted. == PaceOptionalSummary There is a massive amount of support, with two clear -1's. Several of the +1's could see a case for a SHOULD, hence PaceTextShouldBeProvided (see below). This Pace has rough consensus support and is accepted. PaceOptionalXhtmlDiv A handful of -1's, no support, rejected. === PaceOriginalAttribute Number of +1's and -1's approximately equal, plus Ruby pointed out some wording problems. Rejected. PacePubControl Some opposition, but out-of-scope for data format draft. Send back for reconsideration in protocol context. PacePubStatusResource Send back for reconsideration in protocol context. PaceRecommendPlainTextContent Multiple
Re: PaceAllowDuplicateIdsWithModified
On 18/5/05 10:32 AM, Graham [EMAIL PROTECTED] wrote: The first problem is that not all systems track a modified date. If you're obtaining entries using an API on a closed system, and the system doesn't supply a modified date for whatever data you're syndicating, you're screwed. 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). - I modify my atom-generating script to change which optional elements are included. Does the modification date change? - I modify my atom-generating script to change the order elements appear in. Does the modification date change? - I change the location of my entries, and therefore the atom:link element values. Does the modification date change? - I change the location of my entries, and therefore the xml:base attribute on a parent element. Does the modification date change? - I change the email address of an entry's author, but not the entry itself. Does the modification date change? Some of these are format level changes, which would also include - the publisher changes the text encoding - the publisher starts using xml:base and relative references, but without changing the fully resolved location of hrefs Some are content changes, or metadata changes. One suggests a problem with the object model. Don't bother answering yes or no to any of these here. ok, I won't. The point is that even if you do pin down exactly which count as modifications, you have to demonstrate it can easily be implemented and tracked exactly that way on the average CMS (Note adding new columns to the database may not be possible). which is more likely to be supported by the average CMS? an automated date stamp of last modification a user selectable date stamp of last significant update According to http://www.intertwingly.net/wiki/pie/BlogToolDateSurvey it appears that the former is already well supported. e.
Re: Consensus call on last raft of issues
Tim Bray wrote: On behalf of Paul and myself. Atom issues list: http://www.intertwingly.net/wiki/pie/AtomPubIssuesList The volume of correspondence was unfortunately high for an IETF Last Call that came after a Working Group Last call. It is quite possible, as always, that the co-chairs have mis-read the consensus of the group on one or more issues; in which case please push back. We can work on this as long as is needed, and given the passion (and, in some cases, intransigence) we have seen so far, we do not expect to reach unanimity. When you respond to any of these readings of consensus, please do so with the intention of helping the chairs figure out whether or not we have determined consensus, not just to state an opinion one way or another. Thanks! There is a danger of looking at changes in isolation. I will point out two instances that jump out at me. There may be more. PaceAllowDuplicateIDs We see a bunch of +1's with an unambiguous -1 only from Duerst. Sayre was negative (2005/05/05 6:41 AM) but didn't record a -1. Parks has been mostly against, but a close reading of his posts make it clear that his issue is in large part with atom:updated, he remains convinced that readers desire notification of every change however minor and are unwilling to trust publishers' opinions as expressed in atom:updated. He could live with this Pace if we re-introduced atom:modified or inserted wording in the spec emphasizing that if multiple entries with the same atom:id appear in a feed, software must treat them as XXX of the same entry; there was lively debate as to whether XXX was versions, instantiations, or representations. Conclusion: The Pace is accepted. 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. 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? Also, it seemed to me that much of the discussion centered around distinguishing between multiple versions. Reintroducing modified was rejected, and atom:version never made it into a pace, but should there be some hint (perhaps non-normative) that software should look to atom:updated to resolve collisions? = PaceOptionalFeedLink Lots of +1's, moderate objections from Ruby, accepted. http://www.imc.org/atom-syntax/mail-archive/msg14896.html If feed link becomes optional, there is nothing to anchor atom:source elements, which relates back to Bob's objection above. = Finally, I'm not sure what the next step is, but some determination of consensus on extensibility (also referred to as change control) is needed. There does seem to be a lot of voices in support of the following statement: Only those elements defined in IETF RFCs may use the Atom namespace - Sam Ruby
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. Much of the discussion of this pace centered around the proposed changes to section 4.1.2. However, there is more to this pace. - Sam Ruby
