Re: PaceContentAndSummaryDistinct
A. Pagaltzis wrote: The atom:content element either contains or links to the full content of the entry. An atom:entry containing an atom:content element MUST be a complete representation of the entry. If the atom:entry is not intended to be a complete representation of the entry, you MUST use atom:summary instead. The content of atom:content is language-sensitive. +1 ...but isn't the MUST use atom:summary leading to misinterpretation as of title-only feeds? In that it might be understood as you MUST use one of atom:content or atom:summary -- Thomas Broyer
Re: PaceContentAndSummaryDistinct
On May 14, 2005, at 11:02 AM, A. Pagaltzis wrote: The atom:content element either contains or links to the full content of the entry. An atom:entry containing an atom:content element MUST be a complete representation of the entry. -1 What does complete mean? This is untestable and semantically fuzzy. I think anything stronger than is intended to contain the full content is just not workable. -Tim
Re: PaceContentAndSummaryDistinct
* Thomas Broyer [EMAIL PROTECTED] [2005-05-15 17:10]: A. Pagaltzis wrote: The atom:content element either contains or links to the full content of the entry. An atom:entry containing an atom:content element MUST be a complete representation of the entry. If the atom:entry is not intended to be a complete representation of the entry, you MUST use atom:summary instead. The content of atom:content is language-sensitive. +1 ...but isn't the MUST use atom:summary leading to misinterpretation as of title-only feeds? In that it might be understood as you MUST use one of atom:content or atom:summary Yes, youre right. Im not sure what the best way to address that would be; maybe a qualification like If the atom:entry is not intended to be a complete representation of the entry, you MUST instead use atom:summary to carry content. But that is clusmy, I dont like it. * Tim Bray [EMAIL PROTECTED] [2005-05-15 19:35]: -1 What does complete mean? This is untestable and semantically fuzzy. I think anything stronger than is intended to contain the full content is just not workable. In terms of formal verifiability of feed conformance, you are right. In fact, in those terms, there is no way we can clarify the difference between the two elements, at all. Do you suggest that this be left to the implementors guide? Personally, I think the spec should try to make an attempt to nail this down. Maybe the right approach would rather be something along these lines? An atom:entry MUST NOT have both an atom:content and an atom:summary element with identical content. That is a formally verifiable criterion, at least. Regards, -- Aristotle
PaceAllowDuplicateIdsWithModified
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: PaceAllowDuplicateIDs
Thomas Broyer wrote: 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. If you don't update atom:updated (e.g. it's not a significant update, fixing typos, etc.), one could (I would) assume you don't want to archive the previous entry state. Archiving was just an example, but the Publisher and the Archiver are different entities. It is up to the Publisher to decide what they consider to be a significant update, and it is up to the Archiver to decide what they want to archive. There are very few chances that you significantly update an entry with the same second I agree, but this proposal distorts the intended meaning of atom:updated, and I think that this risks atom:updated becoming an unreliable indicator for the newness of entries, which is a shame, because it is a useful feature. -- Dave
Editorial: Language-sensitive
Can we put capital letters on language-sensitive (ie Language Sensitive) the way we do Text Construct, to make it clear it refers to a specific thing and is not a generic term that is meant to be understood on its own? If not, the term is missing its hyphen in section 4.2.9.5, which needs fixing. Graham
Re: PaceContentAndSummaryDistinct
A. Pagaltzis wrote: Personally, I think the spec should try to make an attempt to nail this down. Maybe the right approach would rather be something along these lines? An atom:entry MUST NOT have both an atom:content and an atom:summary element with identical content. You're right, +1 to this -- Thomas Broyer
Re: PaceOptionalXhtmlDiv
Bill de hÓra wrote: Thomas Broyer wrote: I might have not be enough explicit in what I'm suggesting with this Pace: I just want the XHTML div to be optional for people that don't need it but still meeting other people's needs of a dummy container to carry their XHTML namespace declarations. That way, those two summaries would be equivalent: atom:summary type=xhtml xmlns:atom=...Atom NS... xmlns=...XHTML NS... This is a emsample/em summary. /atom:summary summary type=xhtml xmlns=...Atom NS... div xmlns=... XHTML NS... This is a emsample/em summary. /div /summary -1 to PaceOptionalXhtmlDiv. If we are dealing with systems where a div wrapper is deemed neccessary, then you want to take steps to miminise people's options. Do you have examples? div wrappers are necessary only when producers don't want to use prefixes. I propose an elegant solution where meaningless wrappers (div without any attribute, other than namespace declarations) may/should/must be discarded. Atom processors will always have to deal with namespaces (because I can still use prefixes for my Atom and/or XHTML elements, even with the format-08 spec) and actually there is no difference at all between taking the mixed content inside the XHTML div and taking the mixed content inside the atom:content. So the only difference is on the producers side, and people who don't know anything about their XHTML content (and consider it a black box) apart from it to be well-formed and use no prefix, those people can still use a dummy div wrapper acting just like a namespace declaration carrier. I don't see the point. For example, PaceOptionalXhtmlDiv will help this to occur: summary type=xhtml xmlns:atom=...Atom NS... xmlns=...XHTML NS... This is one busted-ass document - emyow!/em. /summary Not more than format-08 won't help this not to occur: summary type=xhtml xmlns:atom=...Atom NS... xmlns=...XHTML NS... div This is one busted-ass document - emyow!/em. /div /summary What will help people who don't know much about XML and namespaces are examples and pieces of advice in the spec. And, actually, people who don't know much about XML and namespace will probably not read the spec but articles published on mass-market web sites... If you can't trust people not to need the div, then you can't make it optional. A div (or span) with no attribute has no meaning at all apart from grouping content, which is already done by the atom:content; so it can be discarded without side effects. I unfortunately have a good amount of experience dealing with this kind of thing outside Atompub. The simplest answer is to stop the 'envelope' from using a default namespace (don't bother to debate this with me, it's not an imo). We're not doing that with Atom. Failing that, the next thing consideration is to add/enforce a protective scoping barrier between the envelope and the content. We are doing that with Atom. The first solution is not on the protocol side but on the producers side: they are responsible of making a well-formed and valid document, just like they make well-formed and valid MS Word, CSV, etc. documents, SQL queries, etc. The second one is on the protocol side. I don't think such a think have to go on the protocol spec. If hacks have to exists to allow prefix-free Atom documents, people wanting them will have to find (it's already done) and use them, without bothering other people with that. There will be conforming Atom processors, Atom validators, etc. Such a namespace error will show as soon as the Atom document will be read/processed by one of them, that is as soon as it will be used. I don't expect much people continue producing such documents if they're not usable... -- Thomas Broyer
Re: PaceContentAndSummaryDistinct
On 15 May 2005, at 10:16 pm, A. Pagaltzis wrote: An atom:entry MUST NOT have both an atom:content and an atom:summary element with identical content. -1 It might solve this exact problem, but in the general case it makes no sense. Let's say I put the first sentence of each post in atom:summary. What happens when I post a one sentence entry? Graham
Re: PaceAllowDuplicateIdsWithModified
On 15 May 2005, at 11:12 pm, David Powell wrote: http://intertwingly.net/wiki/pie/PaceAllowDuplicateIdsWithModified http://intertwingly.net/wiki/pie/PaceDateModified2 +1 But mostly symbolically, because I don't think the atom:modified will fly, and I don't like it much. But it's still better and more complete than the original duplicate ids pace. Graham
Re: PaceContentAndSummaryDistinct
* Graham [EMAIL PROTECTED] [2005-05-16 01:10]: Let's say I put the first sentence of each post in atom:summary. What happens when I post a one sentence entry? Then you must not put it in the summary. And this is my opinion independent of the pace. An even half-way intelligent user agent would do something like display a read more link or button when it displays a summary, to alert the user that there is more to be read, either at the atom:[EMAIL PROTECTED]'alternate'] location or in a supplied atom:content. Would that be applicable to your one-sentence entry? Regards, -- Aristotle
Re: Editorial: Language-sensitive
On May 15, 2005, at 3:18 PM, Graham wrote: Can we put capital letters on language-sensitive (ie Language Sensitive) the way we do Text Construct, to make it clear it refers to a specific thing and is not a generic term that is meant to be understood on its own? +1, good idea. -Tim
Re: PaceContentAndSummaryDistinct
On 16/5/05 7:16 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: An atom:entry MUST NOT have both an atom:content and an atom:summary element with identical content. +1
Re: PaceContentAndSummaryDistinct
* Graham [EMAIL PROTECTED] [2005-05-16 01:15]: An atom:entry MUST NOT have both an atom:content and an atom:summary element with identical content. -1 It might solve this exact problem, but in the general case it makes no sense. Besides my point in the other mail, I wanted to further address this. It does make sense in the general case, in my opinion. A feed producer is expected to pick the element that reflects the payloads nature; this requirement would prevent them from just sticking the same payload in both elements and letting the aggregator sort it out. On a more abstract level, it says atom:summary and atom:content are not the same thing in formally verifiable terms. It does not express the exact role of each element, but that is unenforcable anyway. OTOH, it forces feed producers to pick one element or the other when they only have one piece payload; and it can reasonably be assumed that theyll pick as intended. So it seems to me that it is as close as the spec can get to enforcing correct usage of the elements. Im not wedded to the proposal, but after thinking about it for a while, I believe it actually makes more sense than it seems to at first blush. Regards, -- Aristotle
Re: PaceContentAndSummaryDistinct
On Mon, 16 May 2005 01:16:21 +0200, A. Pagaltzis [EMAIL PROTECTED] said: An even half-way intelligent user agent would do something like display a read more link or button when it displays a summary, to alert the user that there is more to be read, either at the atom:[EMAIL PROTECTED]'alternate'] location or in a supplied atom:content. I think this is the key criterion albeit not a particularly formal one. Which got me thinking: say I provide both a summary-only feed and a full-content feed. I believe it is reasonable to: 1. include a summary element in my full-content feed in addition to the content element; and 2. have some (short) entries in my summary-only feed which contain a content element but no summary. In other words: 1. full-content feed doesn't preclude the existence of a summary element but there will never be a summary element without a content element. 2. summary-only feed really means that the included summary/content won't exceed some arbitrary length. If the content is short enough to fit this, I'll use a content element, even though this is a summary-only feed because the content is complete---there is no read more. James -- James Tauber http://jtauber.com/ journeyman of somehttp://jtauber.com/blog/
Re: PaceContentAndSummaryDistinct
* James Tauber [EMAIL PROTECTED] [2005-05-16 05:45]: I believe it is reasonable to: 1. include a summary element in my full-content feed in addition to the content element; and Absolutely it is. F.ex, user agents could provide the summary in addition to the title of an entry in a feed overview pane, and display either the atom:content or whatever is located at the atom:[EMAIL PROTECTED]'alternate'] URL when you click an entry. Compare NetNewsWires widescreen view. [...] In other words: [...] 2. summary-only feed really means that the included summary/content won't exceed some arbitrary length. If the content is short enough to fit this, I'll use a content element, even though this is a summary-only feed because the content is complete---there is no read more. Indeed. These are all reasons that convince me that within possibility the spec really should try to enforce the distinction: it is an extraordinarily valuable feature of the format for consumers if applied consistently. Regards, -- Aristotle
Re: extensions -- Atom NS and unprefixed attributes
On 5/15/05, Tim Bray [EMAIL PROTECTED] wrote: On May 10, 2005, at 9:14 PM, Robert Sayre wrote: entry fooBar=true title.../title evilExtension / ... /entry Legal? Which part of the spec rules it out? No part. Per http://www.atompub.org/2005/04/18/draft-ietf-atompub-format -08.html#rfc.section.6.2 it's unknown foreign markup, with clear rules for how to handle it, right? Yes, there are clear parsing rules. What's the benefit of allowing such markup? Robert Sayre P.S. -- I've created an atom:drm element. It resides in the W3C namespace and is RFC compliant. Its contents are subject to the provisions of the DMCA. For a small fee, you can read its specification.
Re: extensions -- Atom NS and unprefixed attributes
On May 10, 2005, at 9:14 PM, Robert Sayre wrote: entry fooBar=true title.../title evilExtension / ... /entry Legal? Which part of the spec rules it out? No part. Per http://www.atompub.org/2005/04/18/draft-ietf-atompub-format -08.html#rfc.section.6.2 it's unknown foreign markup, with clear rules for how to handle it, right? -Tim
Re: extensions -- Atom NS and unprefixed attributes
On May 15, 2005, at 9:43 PM, Robert Sayre wrote: evilExtension / Legal? Which part of the spec rules it out? No part. Per http://www.atompub.org/2005/04/18/draft-ietf-atompub-format -08.html#rfc.section.6.2 it's unknown foreign markup, with clear rules for how to handle it, right? Yes, there are clear parsing rules. What's the benefit of allowing such markup? The benefit the Web derived from HTML's implicit-but-universally-implemented MustIgnore rule; it introduced enough slack into the system that people could experiment without breaking things. Related resource: http://www.webratio.com/images/20050408Bosworth.pps More generally: ruling things out should be avoided unless (a) you're really sure they're harmful and (b) you think you can actually successfully enforce it. -Tim
