Re: Preparing the Atom Format Profile Draft
On 24 Jan 2006, at 10:55 pm, James M Snell wrote: Thoughts? It's either not going to be used or will be abused when it is. I can't see it ending well. Graham
Re: atom:content's src and server-driven content negotiation
On 18 Jan 2006, at 12:05 pm, Andreas Sewe wrote: Note, however, that a type attribute on the content element cannot be used since /img is a negotiated resource -- this violates the SHOULD in 4.1.3.2.: 'If the src attribute is present, the type attribute SHOULD be provided [...].' Note the next sentence: The value is advisory So it doesn't have to exactly describe the resource at the other end of the URL. The point is to give the consuming application a useful hint as to what kind of data is there. Which of the above entries is preferable? The correct thing to do is to pick the one provided by default by the server when no content negotiation occurs. eg: content type=image/png href=http://www.example.com/img; / Graham
Re: atom:content's src and server-driven content negotiation
On 19 Jan 2006, at 11:53 am, David Powell wrote: Possibly, but that solution isn't perfect. There is a tradeoff between supplying an inaccurate type, and supplying no type at all. This TAG finding [1] discusses the issue quite thoroughly. [1] http://www.w3.org/2001/tag/doc/mime-respect-20040225 The risk in providing an inaccurate mime-type in the content or link elements, is that a user-agent such as a mobile device, might not attempt to fetch the content at all if they don't support the advisory MIME type, even though if they had requested the type, and conneg had taken place, they could have been served a different type that they could have handled. If you read the W3C finding carefully, it doesn't actually cover this exact problem. It comes close in scenario 2 in section 2, section 4.1 and section 5, but doesn't quite get there - all only cover when the advisory type is wrong outright, rather than misleading because of conneg. The recommendation at the end of section 4.1 seems appropriate though. If the advisory type attribute is incompatible, the client should query the resource to double check, or at least offer the user the option of double checking and/or loading the resource anyway. Graham
Re: partial xml in atom:content ?
On 18 Jan 2006, at 3:06 am, James Holderness wrote: The problem it that proving something is quite likely to work says nothing about whether it would be valid and/or safe, even in the limited context of XHTML. True, but sometimes people have to make decisions based on the limited information available to them. Knowing that something is quite likely to work is better than not knowing anything at all. No it isn't. As for validity, as far as I'm concerned that isn't even in question. I ran the feed through the feedvalidator and it said it was valid. Granted the feedvalidator isn't always right, but my reading of the spec reached the same conclusion. If you think the feedvalidator is wrong, I'd suggest you file a bug report or post to the feedvalidator mailing list. Oh for fuck sake. The feed validator can only check whether something is syntactically correct. It cannot check whether it's semantically correct (ie means what you think it means). I'm sure you know this and are just being an asshat. Graham
Re: partial xml in atom:content ?
On 16 Jan 2006, at 4:59 pm, James Holderness wrote: In theory, yes. In practice, no. Bare in mind that the 0.3 Atom spec had type=application/xhtml+xml with basically the same functionality as the current type=xhtml. Now since Atom 0.3 is still a whole lot more widely used than Atom 1.0, you can be fairly sure than anyone that bothers to handle XML content at all will be capable of handling type=application/xhtml+xml containing xhtml fragments. Speak for yourself. It's crappy assumptions like this that made RSS hellish to work with. Atom is unambiguous. application/xhtml+xml means the page content is a full standalone web page. Graham
Re: partial xml in atom:content ?
On 16 Jan 2006, at 3:09 am, James Holderness wrote: The one time I'd think it might be safe is with XHTML (as I mentioned in a previous message) since Atom processors are already required to handle XHTML fragments in the content element. Anything else would be highly risky unless it was a proprietary feed communicating between two known applications. Except no one bothered to tell the aggregator writers they'd have to implement this, so no it's not safe. Graham
Re: partial xml in atom:content ?
On 16 Jan 2006, at 6:50 am, A. Pagaltzis wrote: okay, another thrust, taking into account the things you said in your reply to the first thrust: is anything wrong with this? entry !-- ... -- content type=application/xml category .../ /content /entry This is valid Atom. Two options: 1) Valid but completely meaningless, since category Atom documents aren't defined anywhere. 2) Invalid, since category Atom documents aren't defined anywhere. Graham
Re: Category URI's
On 9 Jan 2006, at 9:33 pm, A. Pagaltzis wrote: category scheme=http://.../tag; term=?tag=foo label=foo / Blurgh. Graham
Re: Signifying a Complete Feed
On 13 Oct 2005, at 8:02 pm, A. Pagaltzis wrote: If you want to ship a complete representation, you ship an atom:entry, and if the resource is empty, then that atom:content is empty. If the atom:entry has no atom:content, then that always means that it is a partial representation only. Point to any text in the spec that backs this up. Graham
Re: [feedvalidator] amp;apos; is not HTML
On 19 Sep 2005, at 11:20 am, Anne van Kesteren wrote: I assume it was added to sniff for 'HTML like constructs' only this time the subject really was apos; and it was not used to double escape for HTML. Besides that, apos; is not even a valid entity for HTML 4. That's why it says Warning instead of Error. On the other hand, neither of the sentences following it are acceptable to me: This feed is valid, but may cause problems for some users. We recommend fixing these problems. It would be better if the validator admitted it's fallibility and said straight up that it doesn't know if these are problems or not. Graham
Re: The benefits of Lists are Entries rather than Lists are Feeds
On 31 Aug 2005, at 6:22 pm, Roger B. wrote: (1) If the lists are embedded as (X)HTML, then only aggregators that display markup will be able to do anything with them, and headline-only aggregators will be useless. And damn those unthinking bloggers who embed their paragraphs as (X) HTML, because headline-only aggregators are useless for reading them. (2) If the lists are embedded in a new extension of some sort, developers have to buy in to get even minimal functionality. Not so if the entries are list items... even a non-list-aware aggregator will be able to display *something*. Who is advocating this? (3) If the lists are embedded as (X)HTML, my options for re-sorting the list are somewhere between minimal and non-existent. Fair point. In fact, the only benefit I can see (as a user) to lists-within-entries is the ability to easily archive the state of the list. But that's probably better left to aggregator developers to implement as a feature. Another feature is the list can be formatted properly XHTML, considerably improving legibly over a bunch of floating entries. Graham
Re: Top 10 and other lists should be entries, not feeds.
How would this apply to the most problematic example of a list feed, the BBC news headline page: http://newsrss.bbc.co.uk//rss/newsonline_uk_edition/front_page/rss.xml Which has the top stories first (amongst other structure) and is a hell of a lot more usable in news readers that preserve order. Graham
Re: Top 10 and other lists should be entries, not feeds.
On 30 Aug 2005, at 9:01 pm, Mark Nottingham wrote: It sounds like you've got use cases for Atom that other use cases (e.g., lists) make difficult to work with. Banning those other use cases makes things easier for you, but I don't think it's good for Atom overall. But conceptually Bob is absolutely correct. An ordered list is just an entry that gets updated regularly. There's absolutely no reason for Netflix to create an individual entry for each DVD. It's a hack that makes it look better in most aggregators. Nothing more. It would be good if Atom were flexible enough to cope where there isn't a 1:1 mapping between publications and items of information, by subdividing entries into chapters or something, but as Mark Pilgrim said somewhere, Atom deals with none of the interesting problems with syndication (Atom = RSS3). Graham
Re: Don't Aggregrate Me
On 26 Aug 2005, at 7:46 pm, Mark Pilgrim wrote: 2. If a user gives a feed URL to a program *and then the program finds all the URLs in that feed and requests them too*, the program needs to support robots.txt exclusions for all the URLs other than the original URL it was given. ... (And before you say but my aggregator is nothing but a podcast client, and the feeds are nothing but links to enclosures, so it's obvious that the publisher wanted me to download them -- WRONG! The publisher might want that, or they might not ... So you're saying browsers should check robots.txt before downloading images? Graham
Re: If you want Fat Pings just use Atom!
On 23 Aug 2005, at 2:57 pm, Bjoern Hoehrmann wrote: No. See, http://www.w3.org/TR/REC-xml/#sec-terminology, under fatal error. -Tim Yes, exactly what I wrote... the XML processor must report the error to the application and that the processor is not required by the XML specification to continue processing; doing so is however an optional feature and further processing would be implementation-defined vs Once a fatal error is detected, however, the processor must not continue normal processing (i.e., it must not continue to pass character data and information about the document's logical structure to the application in the normal way). Graham
Re: If you want Fat Pings just use Atom!
Just out of interest, how well does any of this work with caches and proxies? Graham
atom:id spec bug
Simon brown raises a valid point on the Spec explanations for Pebble? thread: That same paragraph starts, When an Atom Document is relocated, migrated, syndicated, republished, exported or imported, the content of its atom:id element MUST NOT change.. For me, this paragraph talks about the *Atom Document* moving, rather than the content that it represents (i.e. a blog). Perhaps we could add or its associated resource after Atom Document? Graham
Re: Spec explanations for Pebble?
On 12 Aug 2005, at 9:16 am, Carey Evans wrote: First, where does the spec actually say that the atom:id shouldn't change if the blog moves to a different domain? I think that if the URL of the blog changes, it means that the Atom Feed Document has been relocated so the ID should stay the same, but Simon doesn't see this in the spec. Section 4.2.6, paragraph 3: an atom:id element pertains to all instantiations of a particular Atom entry or feed; revisions retain the same content in their atom:id elements. It is suggested that the atom:id element be stored along with the associated resource. If an Atom document is a feed of the same blog, then even if the blog has moved, the id should stay the same. What makes you think otherwise? Second, what sort of values should be used for the scheme attribute on the category? Looking at http://www.tbray.org/ongoing/ongoing.atom as an authoritative example, it seems that the scheme should be the same for all categories, but Pebble uses the URL of the individual category page. The spec doesn't say, so does it matter? Section 4.2.2.2: The scheme attribute is an IRI that identifies a categorization scheme. categorization scheme means the system used to categorize entries. Presumably each blog has its own system for doing so, so the scheme attribute should be the same for all posts from the same blog, and unique to the blog. Graham
Re: spec bug: can we fix for draft-11?
On 4 Aug 2005, at 11:25 am, Paul Hoffman wrote: That works for me. Another idea is Atom Processors MAY ignore leading and/or trailing whitespace in elements whose content does not allow leading and/or trailing whitespace, such as IRIs and . This doesn't describe an interoperable model. Either all processors must remove whitespace, or whitespace is not allowed at all (Note the latter still allows processors to remove whitespace anyway). Graham
Re: spec bug: can we fix for draft-11?
On 3 Aug 2005, at 2:04 pm, Sam Ruby wrote: A note that Atom processors may consider leading and trailing space as significant in attribute and element values would be enough to alert people to the interoperability issues. +1 Graham
Re: Oversights? (Re: Introduction to The Atom Syndication Format)
On 2 Aug 2005, at 5:41 am, James Cerra wrote: id http://example.com/ /id idhttp://example.com//id Those are different ids (Processors MUST compare atom:id elements on a character-by-character basis), and the first is just plain invalid. Why on earth would you think otherwise? (oh, apparently because the feed validator is broken) Graham
Re: spec bug: can we fix for draft-11?
On 2 Aug 2005, at 10:07 am, Bill de hÓra wrote: The design intent of character-by-character cmp as I understood was for the URI contained by the element. I think confusing the element content with the URI is a spec bug. From atompub-format-10, 4.2.6: Its content MUST be an IRI That to me is demonstrates a very clear intention of the working group that the content must be exactly equal to the IRI. Changing this to allow whitespace would represent a major technical change to the format. I will figuratively lie down in the road if anyone suggests whitespace should be allowed around any machine-read content (uris, @type, @rel, etc). Graham
Re: spec bug: can we fix for draft-11?
On 2 Aug 2005, at 12:50 pm, Ian Davis wrote: The two examples that Bill gave WILL happen in the wild and Atom consumers will just deal with it by stripping the whitespace anyway despite what the spec says now. I think this should be endorsed in the spec for interoperability. I (and probably others) have already put code out into the wild in the assumption there is no whitespace. As I said before, it's too late for a solution that changes the meaning of the spec. Graham
Re: spec bug: can we fix for draft-11?
On 2 Aug 2005, at 5:46 pm, Sam Ruby wrote: As it stands now, the spec does NOT clearly outlaw leading and trailing whitespace from ids I've been trying to argue with this but I can't find a normative reference that explains what the content of an element is. This is perhaps a bigger problem. Graham
Re: spec bug: can we fix for draft-11?
On 2 Aug 2005, at 9:07 pm, Robert Sayre wrote: For me, the most disturbing aspect of this debate is that any resolution will provide very, very little interoperability gain. Agreed. All we need to do is decide one way or the other what the spec should say. That said, I certainly wouldn't object to any text warning people not to do it, or explicitly mentioning that you have to call the equivalent of String.trim(). Recommending the former would draw attention to the issue and perhaps encourage the latter. (Or make both explicit, with SHOULD and MAY). Graham
Re: Atom namespace, qname-uri-qname roundtripping
On 31 Jul 2005, at 1:53 pm, Benjamin Nowack wrote: as the atom namespace is declared as http://www.w3.org/2005/Atom; (i.e. without a trailing separator such as / or #), term URIs from atom documents are expanded by xml parsers to - http://www.w3.org/2005/Atomfeed - http://www.w3.org/2005/Atomtitle Exactly which part of the XML namespaces spec backs up this behaviour? Graham
Re: Atom namespace, qname-uri-qname roundtripping
On 31 Jul 2005, at 4:01 pm, James Cerra wrote: That's apparently what libxml does. As you can see, with Atom's namespace it is a mess. It is also a mess with XHTML's namespace, XSLT's namespace, and most document-oriented namespaces. Were the RDF folks not smart enough to think of this problem and come up with a better system or a workaround? is simply appended to the beginning of the no-colon name: http://www.w3.org/2005/Atomfeed I'm off to start the Atomf working group which will produce a standard specification for eed documents. Graham
Re: Proposed changes for format-11
On 1 Aug 2005, at 1:07 am, Sam Ruby wrote: If neither the type attribute nor the source attribute is provided, Atom Processors MUST behave as though it were present with a value of text. And what is this mysterious source attribute? I presume you mean src, but it is not expanded to source anywhere else in the document. Graham
Re: Comments Draft
On 30 Jul 2005, at 1:38 am, A. Pagaltzis wrote: * James M Snell [EMAIL PROTECTED] [2005-07-30 01:40]: It's really just a hint as to where original entries MIGHT be found. “originally-at?” source? Graham
Re: Media type treatment in the processing model
We have simple rules so that for any media type there is only a single possible encoding method that everyone agrees upon. This means clients can know exactly any type of content they come across was encoded. If there are media types that don't fit the normal pattern of naming, they may end up using an illogical encoding method. I don't necessarily support this arrangement, but it's definitely far superior to what we had before where the publisher could choose any method which made decoding at the client tremendously complicated. Graham
Atom error pages
It's far too late for this, but how should Atom servers produce/ clients deal with error pages? Feedster regularly changes its search results feed to a single entry Search results temporarily offline feed document (RSS guid http://www.feedster.com/;), and I think served with HTTP status 200. This seems the wrong behavior for so many reasons. What should they be doing in Atom? Graham
Re: Atom error pages
I might see where Graham is coming from. Graham are you talking a case where the feed/entries are being elided with not-available messages? I think so. The problem with using HTTP error codes is that in many clients the result is far less pretty. For example, in Shrook you get a warning sign next to the feed name, which when clicked produces a generic error message for the HTTP code. The thing is, publishers want errors to be prettier and better explained. Returning a 200 and a feed document containing an error message entry produces predictable results in all clients, with the side effect of polluting the feed history. The results of doing both (an HTTP error code and a custom Atom error document) need to be predictable. Whereas most web browsers will display a custom HTML error page (IE excepted), most Atom clients won't do anything with the body of a non-200 response (I think). Graham
Re: Atom error pages
On 25 Jul 2005, at 9:26 pm, James M Snell wrote: Returning an atom entry document would likely work fine when one is requesting an Atom feed document, but it could lead to confusion if the expected non-error result is itself an atom entry document. How does one differentiate the expected non-error result from the error result. The HTTP code? Graham
Re: Notes on the latest draft.
On 21 Jul 2005, at 4:43 am, James Cerra wrote: In an XSLT-based Atom-to-XHTML processor, that is a large cost when HTML includes many many many entities. At least, I think so and have ignored the problem because I can't think of a good way to solve it. Yes, but your proposed solution just requires people at the other end of the chain to do the hard work. A common theme in the design of Atom is minimizing the amount of work that must be done by publishers (of which there are many) vs the amount of work done by processing tools (of which there are few, and which are easier to turn into common libraries). Graham
Re: Notes on the latest draft.
On 21 Jul 2005, at 7:29 pm, James Cerra wrote: Graham, Yes, but your proposed solution just requires people at the other end of the chain to do the hard work. A common theme in the design of Atom is minimizing the amount of work that must be done by publishers (of which there are many) vs the amount of work done by processing tools (of which there are few, and which are easier to turn into common libraries). You are probably correct. However... Aren't HTML's character references harder for publishing software to produce compared with HTML numeric references? After all, producing numeric references requires a simple fast algorithm and no lookup table. Thus, depreciating HTML character references makes it _easier_ to publish Atom code as well. Not if the HTML in the publishers database already contains named references, and/or users are regularly submitting HTML that contains named references. The only feed producer software that probably likes HTML character references above all else are human hands. And if humans are writing their feeds by hand, then. Feeds a generally a small facet of a much larger publishing system or process, that yes, includes humans. Graham
Re: Notes on the latest draft.
On 20 Jul 2005, at 6:08 am, James Cerra wrote: I feel that HTML entities other than numeric references, amp;gt;, amp;lt;, amp;amp;, amp;apos;, and amp;quote; should be depreciated in HTML content. Disagree. All it needs is a simple look-up table in the HTML parser. Atom should explicitly endorse XHTML over HTML as perferred form of content. HTML is just really hard to process compared with XML. If you say so. There is no reason *not* to change this to atom:id. It is lazy and dangerous to have an element lie about the type of its content. Furthermore, the whole point of atom:uri is the same as atom:id - to identify the thing they refer to (author or entry) - and their content is likewise identical. There is no reason to think that it is either unique to an author or will be the same for every reference to a particular author. It's a useless identifier. OTOH, is there a reason that atom:uri (which should be atom:indentifier) and atom:email are not attributes of a person construct? To allow easier, consistent extension. Graham
Re: FormatTests
On 16 Jul 2005, at 11:27 am, Graham wrote: Also: Solution: Use the canonical form, given in the warning message. It now says: All newly issued ids should be in canonical form. Use the canonical form given in the warning message for guidance. (http://feedvalidator.org/docs/warning/NonCanonicalURI.html) While an improvement, it needs to say that old ids cannot be corrected and the old thing you can is prevent it happening in future. It might therefore be simpler to not flag this problem at all. Now do you see why canonical ids are stupid and irrelevant? Graham
Re: Atom 1.0 xml:base/URI funnies
On 17 Jul 2005, at 4:20 pm, Sjoerd Visscher wrote: Where did you read that same-document references only apply when there is no embedded base URI? Scroll down to the algorithm in 5.2.2, and it backs up Tim and Sam, in particular this: if (R.path == ) then T.path = Base.path; It seems pretty clear to me that whoever wrote the same-document references section simply wasn't thinking about embedded base URIs, and thus it can be safely ignored. Your interpretation would contradict not just the algorithm but practically the whole of the rest of the document. Graham
Re: FormatTests
On 15 Jul 2005, at 11:20 pm, Sam Ruby wrote: Can you be more specific? If I plug my new Atom 1.0 feed into the validator: http://www.feedvalidator.org/check.cgi?url=http%3A%2F% 2Fwww.fondantfancies.com%2Fblog%2Fatom1%2F Last night, it said the feed wasn't valid, but today it's saying: Warning: This feed is valid, but may cause problems for some users. We recommend fixing these problems. I'm not sure about this wording, but providing a warning is fine. Also: Solution: Use the canonical form, given in the warning message. Are you advocating changing permanent identifiers? Bad Sam. ID canonicalization was a bloody stupid idea. Graham
Re: The Atomic age
On 15 Jul 2005, at 4:56 pm, Walter Underwood wrote: Do we have a list of who is implementing it? That could be used in the Deployment section of http://www.tbray.org/atom/RSS-and-Atom. My blog has one here: http://www.fondantfancies.com/blog/atom1/ I think it's valid, though it's hard to tell without a validator or even a parser. I'm currently rewriting the engine of Shrook to be compatible too. (You may also notice I'm doing my little bit to make sure atom:id is implemented properly) Graham Parks
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
On 17 Jun 2005, at 6:14 pm, Tim Bray wrote: Uh, has Mark spotted a dumb bug here that we should fix? Do we care if *remote* content is of a composite MIME type? My feeling was that we ruled out composite types in *local* content, for fairly obvious reasons. The fix is obvious, in 4.1.3.1 I don't think it's a dumb bug. A composite type is more than a single piece of content. Using atom:content this way is wrong, since conceptually it produces this: atom:entry atom:titleMessage Subjectatom:title atom:authoratom:nameAn author/atom:name/atom:author atom:content !-- Translating the email headers to Atom -- atom:titleMessage Subjectatom:title atom:authoratom:nameAn author/atom:name/atom:author atom:contentMessage body/atom:content /atom:content /atom:entry The better way to do this is to use atom:link rel=alternate to reference the messages. -1 to the proposal, at least for this use case. Graham
Re: I-D ACTION:draft-ietf-atompub-format-09.txt
On 8 Jun 2005, at 9:59 pm, Antone Roundy wrote: atom:content MAY have a src attribute, whose value MUST be an IRI reference [RFC3987]. If the src attribute is present, atom:content MUST be empty. Atom Processors MAY use the IRI to retrieve the content, and MAY NOT process or present remote content in the same manner as local content. It took me a second to realize that MAY NOT means don't have to rather than aren't allowed to. The technical meaning of the terms is perfectly clear, but it's quite different from the usual meaning of those words, and may be misunderstood. It might be better to say Atom Processors MAY use the IRI to retrieve the content, and MAY process or present remote content in a different manner from local content. +1 and MAY process or present remote content in a different manner to local content Graham
Re: The atom:uri element
-1 to atom:link unless they are proper link elements. I'm fairly happy with the current situation. Graham
Re: The atom:uri element
On 25 May 2005, at 2:25 pm, Asbjørn Ulsberg wrote: What about atom:[EMAIL PROTECTED], then? No, I want multiple uris. I've just checked the spec and noticed it doesn't allow them. Why? Shouldn't I be able to have an http: uri and an aim: uri? And couldn't email be a mailto: uri? +1 to replacing atom:email and atom:uri with multiple real atom:link elements (to allow titles). (I don't care about the rel value) Graham
Re: Consensus snapshot, 2005/05/25
On 25 May 2005, at 7:35 pm, Antone Roundy wrote: If multiple atom:entry elements originating in the same Atom feed have the same atom:id value, whether they exist simultaneously in one document or in different instances of the feed document, they describe the same entry. I'm going to write a Pace right now, in case that will make any difference. Comments? What about when they don't? I don't see any value here. A line saying that when two matching entry ids found in different feeds is fine, but (apparently) saying it's completely meaningless goes way, way too far. (Also, do we have a definition for Atom feed that exists beyond a single instance of a feed document?) Graham
Re: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25)
On 25 May 2005, at 9:01 pm, Antone Roundy wrote: 8.5 Denial of Service Attacks Atom Processors should be aware of the potential for denial of service attacks where the attacker publishes an atom:entry with the atom:id value of an entry from another feed, and perhaps with a falsified atom:source element duplicating the atom:id of the other feed. Atom Processors which, for example, suppress display of duplicate entries by displaying only one entry with a particular atom:id value or combination of atom:id and atom:updated values, might also take steps to determine whether the entries originated from the same publisher before considering them to be duplicates. How is this a Denial of service attack? Isn't it just ordinary spoofing/impersonation? Apart from that, +1. Graham
Re: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25)
On 25 May 2005, at 10:05 pm, Antone Roundy wrote: But is it not potentially a DOS? The Good Guy publishes an entry. The Bad Guy copies the atom:id of that entry into an entry with different content, gives it a later atom:updated, and publishes it. The aggregator stops publishing/displaying the Good Guy's entry and instead publishes/displays the Bad Guy's entry. Thus, the subscriber doesn't see the Good Guy's entry (unless they saw it before it was replaced). Technically, yes, it is denial of service. But the term Denial of Service refers specifically to attacks where the main objective is to prevent a service being accessible. Replacing content does deny service, yes, but it's also a lot more than that. Graham
Re: atom:type, xsl:output
On 24 May 2005, at 5:06 am, James Cerra wrote: First off: it is an error to lie about your media-type, so I would change SHOULD be suitable for handling as the indicated media type to MUST be suitable for handling as the indicated media type. +1 Secondly, XML may be entity (or CDATA) encoded like @type=html or plain xml like @type=xhtml. This is becuase of the content of atom:content MAY include child elements phrase. There is no guarantee if an entity escaped passage is xml or a text node example of an xml document (i.e. an example of an xml document), for example. If I follow you right, you misunderstand. Atom documents are unambiguous. XML has to be inserted literally, with no entity escaping (except for entities that are part of text nodes) allowed. atom:content type=application/xml lt;?xml version=1.0? lt;tag //atom:content This is invalid, since it has no root element. It represents the standalone XML document: ?xml version=1.0 lt;?xml version=1.0? lt;tag / This is correct: atom:content type=application/xmltag //atom:content Graham
Re: atom:source
On 24 May 2005, at 2:23 am, Robert Sayre wrote: Disagree, the MAY is about putting atom:source in at all (yes, it's possible to copy entries without using atom:source). The text implies that the source must be an atom:feed element, and those have required elements. The RNC also requires atom:title and atom:updated, etc. I guess we could add All required feed metadata elements MUST be present. OK? I think the thing it's missing is All elements MUST be copied when creating an atom:source from an atom:feed Graham
Re: some small comments on 08
On 24 May 2005, at 9:40 am, Henri Sivonen wrote: On May 23, 2005, at 12:31, Julian Reschke wrote: For the record: I am +1 on http://www.intertwingly.net/wiki/pie/ PaceOptionalXhtmlDiv. -1, and additionally I don't think the Pace is even complete or reliably implementable. Graham
Re: extension elements inside link elements?
On 24 May 2005, at 4:07 pm, Robert Sayre wrote: 4.2.9 (editorial): The atom:link element is explicitly described as empty, which violates the rules in 6 for foreign element extension. Remove is an empty element that. That's not an editorial change, that's newly allowing extension elements in a place most people (such as Paul and myself) assumed they weren't. Graham
Re: atom:type, xsl:output
On 23 May 2005, at 9:14 am, Danny Ayers wrote: * When @type=html then the content of the element is a xsd:string [1] of an HTML DIV element plus optional insignificant whitespace around it. Which version of HTML is defined? How do you differentiate between HTML 4.01, HTML 3.2, the upcoming HTML 5, or nonstandard HTML (like with marquee elements)? I believe the answer would be street HTML, not any specific version. * When @type=mime/type [2], ONLY for atom:content, then the content (or src document) is that type of document. Why not allow other elements to use this? Because the other elements are for purely textual content. XML 1.1 Not supported. Turtle Don't know. RTF It is compatible, as a string, though certain obsolete characters are not. PNG Should be base64 encoded. What should one do when encountering these situations? See section 4.1.3.3 Processing Model Does that mean that if you use application/xhtml+xml, you can do (rest of feed omitted for brevity): Yes. This is why we have a special XHTML mode for fragments. Graham
PaceClarifyAuthorContributor posted
http://www.intertwingly.net/wiki/pie/PaceClarifyAuthorContributor == Abstract == Allow multiple authors. Clarify relationship between atom:author and atom:contributor. == Status == Open == Rationale == The current draft only allows one atom:author per entry, meaning either: - All authors of a document have to be shoehorned into that atom:author element - One author has to be chosen as primary and the rest are contributors Secondly, no explicit relationship is given between author and contributor atom:contributor. The most intuitive approach, and that outlined in this pace, is that each person involved should only appear in one role (as an author, or as a contributor). Also, for the sake of making processing at the display end easier, each person should only be mentioned once. == Notes == Neither bylines nor inheritance are dealt with by this Pace. == Proposal == In 4.1.1, replace: o atom:feed elements MUST contain exactly one atom:author element, UNLESS all of the atom:feed element's child atom:entry elements contain an atom:author element. with: o atom:feed elements MUST contain one or more atom:author elements, UNLESS all of the atom:feed element's child atom:entry elements contain at least one atom:author element. Remove: o atom:feed elements MUST NOT contain more than one atom:author element. In 4.1.2, replace: o 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. With: o atom:entry elements MUST contain one or more atom:author elements, 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. Remove: o atom:entry elements MUST NOT contain more than one atom:author element. Add: o Within the atom:author and atom:contributor elements an atom:entry contains, any single Person SHOULD NOT be mentioned more than once. == Impacts == Listing several people in a single atom:author element and then crediting them individually as atom:contributors is consciously barred by this pace, in anticipation that a separate byline element may be introduced if the functionality is required. CategoryProposals
Re: PaceClarifyAuthorContributor posted
On 23 May 2005, at 12:15 pm, Robert Sayre wrote: -1 to this part. Why would you bar it? There is no right answer, so just let it be looser. Because we have to have this line: Within the atom:author and atom:contributor elements an atom:entry contains, any single Person SHOULD NOT be mentioned more than once. Anything looser makes it very hard to interpret the intended meaning of a set of atom:author and atom:contributor elements programmatically. Please describe a suitable algorithm if you wish to remove this constraint. Graham
Re: PaceClarifyAuthorContributor posted
On 23 May 2005, at 12:28 pm, Robert Sayre wrote:
What is the interop problem you are trying to avoid? You don't just
throw in a SHOULD NOT and say otherwise it would be hard.
With the line in place, generating a basic byline is as simple as:
print by '
foreach (atom:author) print atom:author.name;
if (count(atom:contributor)) {
print with contributions from ;
foreach (atom:contributor) print atom:contributor.name;
}
Without that line, the code has to do duplicate detection (including
looking for a name in a list of names, that may be formatted
differently). It is impossible to do this with 100% reliably. Hence
the SHOULD NOT.
Graham
Re: PaceClarifyAuthorContributor posted
On 23 May 2005, at 1:09 pm, Robert Sayre wrote: Fully disagree. Try a record album by the Rolling Stones or Grandmaster Flash and The Furious 5. OK to list the band members as contributors? Definitely. Maybe there's a minor bug in the wording here, but the restriction is not intended to block that (mentioning the band and then the member would not count as mentioning someone twice), and the pseudocode I proposed would produce more-or-less sensible results. In any case, the alternative you propose is no model at all, and anything created under would not be decodeable programatically, unless you can provide psuedocode that proves otherwise. Graham
Re: PaceClarifyAuthorContributor posted
On 23 May 2005, at 3:45 pm, James Aylett wrote: Why can't we just have the semantics that if you have two Person constructs, you'll get the effects of having two Person constructs? That way it's up to the producer of the feed - if they want the semantics that they'll have identical names listed twice in author lists, indexes or whatever, they can do that. That's the intention of the spec, and the restriction. If you can come up with better wording, then we can go with that. The other intention is that one person shouldn't (and doesn't need to be) listed as both an author and a contributor (ie a author is by definition a contributor). Does anyone object to that? Graham
Re: PaceClarifyAuthorContributor posted
On 23 May 2005, at 2:55 pm, James Aylett wrote: -- atom:author atom:personatom:nameAnne Rice/atom:name/atom:person atom:personatom:nameHoward Allen O'Brien/atom:name/ atom:person /atom:author -- then I've hacked around your restriction. That's still the same person listed twice. As I understand your wording, it's violating the spec - but it's undetectable. No way on earth any Atom processor that isn't a human being is going to notice, so how can we reasonably put that as a restriction in the spec? That's exactly why there's a restriction, because the processor can't tell for itself what's going on, so it needs the publisher to provide correct data about what's what. With the restriction, the processor can safely treat them as separate people and tell the end user This entry was written by Anne Rice and Howard Allen O'Brien. Without the restriction, all it can conclude is The names Anne Rice and Howard Allen O'Brien are in some way related to the authorship of this entry Graham
Re: PaceClarifyAuthorContributor posted
On 23 May 2005, at 4:58 pm, Tim Bray wrote: Uh, Graham, I thought your Pace did a good job of capturing the consensus that seems to be emerging, and then slipped in just a little extra with the name-duplication rules. I'm with Rob, that stuff is past the 80/20 point, I'd suggest you pare down the Pace as a friendly amendment. -Tim Pared down. Graham
Re: PaceClarifyAuthorContributor posted
On 23 May 2005, at 4:52 pm, Robert Sayre wrote: Exactly. It's extremely easy to think of cases that don't fit the model proposed. Consider the Huffington Post, where the feed might list Arianna Huffington as the author, and everybody else as a contributor. But, it would make sense to list her as a contributor as well. Why? She's already credited as the author. If you can explain why that isn't completely redundant and confusing to software, a gold star to you. Graham
Re: posted PaceAuthorContributor
On 23 May 2005, at 6:20 pm, Tim Bray wrote: this feels like trying to legislate morality. --Tim If I want to give someone full credit for an entry, do I: a) Just credit them as an author? b) Or do I need to credit them as an author and a contributor? If (a) is enough, what happens when someone does (b)? Or if the answer is (b), does someone else doing (a) imply that that author contributed nothing? Implementers need to know this stuff. Graham
Re: posted PaceAuthorContributor
On 23 May 2005, at 6:52 pm, Tim Bray wrote: I suspect most people would guess right, and a culture of doing the right thing would develop. Dave, impersonating Tim like this is not on. Graham
Re: posted PaceAuthorContributor
On 23 May 2005, at 7:44 pm, Dan Brickley wrote: What we have today is http://dublincore.org/documents/dcmi-terms/#H2 An entity primarily responsible for making the content of the resource. (Examples of a Creator include a person, an organisation, or a service. Typically, the name of a Creator should be used to indicate the entity.) The WG consensus in supporting multiple atom:authors seems to be against having a singular creator, so -1 on this change. Graham
Re: inheritance issues (was: Author and contributor)
On 24 May 2005, at 12:31 am, Eric Scheid wrote: Second area of concern with writing the spec text - the atom:source element needs to be mentioned in the text about inheritance. My understanding is that inheritance draws first from atom:source (if it exists), and then atom:feed. I'd say it draws from atom:source OR atom:feed. atom:feed should not be used if atom:source exists, even if it doesn't contain an atom:author, which it SHOULD. (unrelated question: what's with this plus sign atomLink+ in the atom:source production?) Graham
Re: Fetch me an author. Now, fetch me another author.
On 22 May 2005, at 1:09 pm, Robert Sayre wrote: No longer sure? I suggest you never will be, since the meanings of the elements are right there in the draft, as is the cardinality. It seems reasonable to conclude you people can't read. No, we just read it a different way to what you do, the obvious way. The idea that atom:autho and atom:contributor are independent is just about a valid reading but completely counter-intuitive. There is a problem here. Graham
Re: Fetch me an author. Now, fetch me another author.
On 21 May 2005, at 1:59 am, Tim Bray wrote: Let me speak as a victim of a few years in the publishing-software trenches: The semantics of author and contributor are a tangled mess, a real swamp, and I don't think that Atom is going to do a very good job of solving them. In particular, I don't think we're going to a better job than Dublin Core. Why are we using author instead of creator then? The current setup is a rushed kludge that came about before we started thinking things through, not a conscious decision to echo Dublin Core. That is to say, if we were to do as some suggest (nuke atom:contributor and make atom:author repeatable) I'm quite certain that we could come up with all sorts of corner cases and problems, probably about as many as with the current setup. You can say that about anything. A flat list of people associated with an entry is infinitely better than the weird one author/multiple contributors model that doesn't offer a clear way to cope with the common model of multiple co-authors. Graham
Re: Accidental and intentional atom:id collisions
The appropiate answer to this is to say comparing an id from a document retrieved from one URI to an id retrieved from a second URI is not reliable. This makes feed:ids largely useless. The primary use, of comparing with a previous version of a document retrieved from the same URI, is fine. Graham
Re: Refresher on Updated/Modified
On 21 May 2005, at 2:41 am, Robert Sayre wrote: OK. The chairs' latest text reads: If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they describe the same entry and Atom Processors MUST treat them as such. Where does the bad behavior come in, and what can we do to discourage it? This line: Their atom:updated timestamps SHOULD be different What are the allowable exceptions here? If I wanted to store two versions with the same id and updated (say from two different sources, or which non-siginificanr differences, is that allowable. What should a client that implements the typical behavior ... to display only the entry with the latest atom:updated timestamp do? Graham
Re: Accidental and intentional atom:id collisions
On 21 May 2005, at 1:51 pm, Henry Story wrote: That makes sense. But then it only gives one a very limited ability to move an entry from one place to another. If the entry has to be located in the same feed, then presumably that means that it would be difficult to move the entry from one domain to another. The feed becomes a redirect and the aggregator can reliably compare ids across the old and new addresses. Not hard. Graham
Re: Fetch me an author. Now, fetch me another author.
On 21 May 2005, at 3:30 pm, Robert Sayre wrote: On 5/21/05, Graham [EMAIL PROTECTED] wrote: The appropriate way to decode this is Written by Graham with contributions from Friend 1 and Friend 2 Lets decode your sample in the same way: Written by Yuri Fialko, David Sandwell, Mark Simons Paul Rosen with contributions from Yuri Fialko, David Sandwell, Mark Simons and Paul Rosen Which makes no sense. The two usages are incompatible, and the spec needs to say which is correct. What makes you think 'authorship' is arrived at by composing atom:author and atom:contributor elements. It's the impression I've had for nearly 2 years. If I'm wrong, then fine, but there's nothing in the spec that says anything either way. Graham
Re: multiple atom:author elements?
On 20 May 2005, at 4:41 am, Eric Scheid wrote: 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. The one author restriction isn't really necessary. My only problem is with our order is not significant rule since there's a strong likelihood that authors will be displayed in the the order they appear in the XML, and that publishers will expect it. Graham
Re: multiple atom:author elements?
On 20 May 2005, at 4:12 pm, Robert Sayre wrote: Well, the two examples we've been shown want to control presentation when multiple authors are grouped. Raggett, D, Hors, A, and I Jacobs Yuri Fialko, David Sandwell, Mark Simons amp; Paul Rosen The logical answer would then be a new element for that label when multiple atom:authors are present. Does anyone remember the reason we have atom:contributor? I say drop it. Graham
Re: PROCESS QUESTION: are we done yet?
On 20 May 2005, at 8:02 pm, Paul Hoffman wrote: Does the WG want to be able to open up new topics, or re-open old topics with a twist? If so, do we all agree to the delay in publication that comes with that? Also, how long should this opening and re-opening last? Are there any limits on which parts of the spec we are willing to change? I think the last deadline was premature and totally out of sync with the WG, and if anything is responsible for the delay, because of the temporary cessation of new Paces. There probably needs to be one more round of discussion on recent changes like duplicate IDs, but everything else seems finished. I think there will be a natural ending soon enough. Graham
Re: Refresher on Updated/Modified
Tim, can I ask about your thinking regarding the use of atom:updated in PaceDuplicateIDs. What if someone (either the publisher or someone downstream) wants to store a history of every revision in an archive feed? atom:updates forces one to choose only one version per significant change. The mechanism it affords (being able to automatically display the newest version) is vital, but it doesn't seem like the best way to do it. Graham
Re: Refresher on Updated/Modified
On 21 May 2005, at 2:15 am, Robert Sayre wrote: On 5/20/05, Graham [EMAIL PROTECTED] wrote: Say I'm aggregating feeds into a search results feed, and I get the same entry twice (with the same atom:id and atom:updated), from different sources. Would it be acceptable to me to adjust the atom:updated by one second and put both in the results, to show the end user the entry was available from two places? I think you are conflating timestamps and version identifiers. Just to be clear then, my example was meant to be of the sort of bad behavior PaceDuplicateIds encourages, not of something I'd want to do. It's the Pace that'd doing the conflating. Graham
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: 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: PaceAllowDuplicateIdsWithModified
On 18 May 2005, at 6:01 am, Eric Scheid 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. Some are content changes, or metadata changes. I see no discussion of this distinction in the atom:modified proposal. an automated date stamp of last modification a user selectable date stamp of last significant update atom:updated does not have to be user selectable. It's perfectly valid to leave it as the first publishing date, or to use a last modification date. (Not that either of these are useful - I think atom:updated should be optional, but Tim doesn't listen) Graham
Re: Consensus call on last raft of issues
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) The atom:summary element can be omitted if the Atom entry is generated for an application with known requirements that make the inclusion of an atom:summary element impractical (such as limited bandwidth). However, when some general-purpose applications encounter such entries, those entries might be ignored. I like this. Regardless of how an associated application will handle entries with no atom:summary element, all Atom Processors MUST NOT fail to process Atom entries simply because they contain no atom:summary or atom:content element. Do we have a definition of process (and/or fail)? Graham
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: 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
Re: PaceAllowDuplicateIdsWithModified
On 16 May 2005, at 2:02 pm, Eric Scheid wrote: what about comparing that entry against other entries? how do you sort a set of entries into chrono order? We have atom:updated and atom:published for that. The value does not need to correspond to any particular event in an entries life-cycle. Suitable values include date of last modification, or the date the atom:entry is generated by an Atom producer. does this mean that a dynamic system could cause the same entry to have a new modification date on every retrieval? i) It's not a modification date ii) Yes. The point of atom:modified and atom:version is to differentiate 2 different versions. Dynamic dates do that perfectly well. Graham
Re: PaceAllowDuplicateIdsWithModified
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. What if the Archivist is not the Publisher? They will then see many many instances, all with different 'versions' ... are they to assume they are different versions/editions, and put each and every dynamic instance into the archive? You'd be keying off a semantic atom:version doesn't have, which is a daft thing to do. If you want to determine which versions to store, wait for the content itself to change. Graham
Re: PaceAllowDuplicateIdsWithModified
On 16 May 2005, at 6:06 pm, Eric Scheid wrote: I'm saying that atom:version is an inferior proposition as compared to atom:modified. Your original premise of there being only two properties we're interested in is faulty. With respect to allowing duplicate ids, it isn't. Graham
Re: extensions -- Atom NS and unprefixed attributes
On 16 May 2005, at 5:59 pm, Tim Bray wrote: i) Don't you think the Feed Validator should flag my example as invalid? No. ii) I actually thought that what we meant was what the spec said, and that this was the (very reasonable) outcome of our discussion on MustUnderstand. That means that if the IETF wants to extend Atom, we can do it as long as the extensions can be safely ignored. If you want to put something new in that can't be safely ignored, the whole document namespace has to be changed. I thought that the WG had converged on a reasonable and in fact enlightened position and I really would prefer not to go back and repeat the discussion. -Tim Extensions being safely ignored is not the same thing as random crap in the Atom namespace. Robert's example was bogus in this regard, since there's no such thing as an evil extension. On the other hand, I can't see any reason to allow third parties to create extensions in the atom namespace, other than to create problems for ourself when it come to v1.1. Graham
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
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: PaceOptionalXhtmlDiv
-1 Misunderstands what the div is for (ie a very elegant solution to a difficult problem, with a maximum cost of 11 bytes to those that solve the problem in other ways). Graham
Re: PaceContentAndSummaryDistinct
On 14 May 2005, at 5:36 pm, Kevin Marks wrote: After seeing 'in the wild' what I consider badly-formed Atom feeds, where both the atom:summary and atom:content contain identical abbreviated entry text, I realised that the spec does not make this clear. As this is a key advantage of Atom, I thought it best to make this explicit, hence: http://www.intertwingly.net/wiki/pie/PaceContentAndSummaryDistinct I support the sentiment, but the way it's written is awful. We could just change: The atom:content element either contains or links to the content of the entry To: The atom:content element either contains or links to the full content of the entry (or complete, or the adjective of your choice) Graham
Re: Last Call: required summary or content?
On 11 May 2005, at 10:58 pm, Robert Sayre wrote: I don't know what your goal is, so I'm just throwing things out there to see if they're what you want. Please explain your problems with each option, and I will try to work with you. Please note that the interests of other implementors and users may not line up with yours. The Implementor's Guide may or may not ever exist and may or may not be read by anyone, so that isn't an option. Myself and Sam, and (I think) Tim and Antone, would all like the actual spec to make an actual recommendation that entries without enclosed content include a textual summary, if at all possible. Note no one wants to ban title- only feeds if they come from title-only resources. What language would you find acceptable that covers these bases? Graham
Re: Last Call: required summary or content?
Robert, I'm trying to include you in this discussion and you're not cooperating. You are the only person in the WG who has said there shouldn't be any recommendation in the specification. You are vastly outnumbered by people who've stated they'd be OK with it. The only question now is the wording. Graham
Re: Last Call: required summary or content?
On 12 May 2005, at 1:51 am, Bill de hÓra wrote: The WG has tended to punt assuming on a Fabled Implementors Guide. Why is that punt not acceptable now? I know putting things in the IG has been mentioned before, but I can't think of any actual cases where that was the outcome of the debate - things have either been put in the spec, or rejected outright. This needs to go in the spec. It's just as much of an techical/interop issue as Logos must have a 2:1 aspect ratio. Bray voiced concerns about SHOULD; I suggested MAY. No further discussion occurred. What might be wrong with a MAY requirement in this case? MAY is fine as the actual RFC term, but needs to be embellished, eg: atom:summary MAY be included, but software is encouraged to do so when atom:content is not present As I've said before, I don't know what the exact wording needs to be. Is there an RFC-compatible way to get the intention of this sentence across? This question is put mainly to the chairs and the AD, btw. Graham
Re: PaceFeedIdOrSelf
On 10 May 2005, at 2:12 am, Antone Roundy wrote: Why not? Because: a) It's not possible to compare an atom:id with a rel=self link. It's perfectly possible for the URI in atom:id to be the same as the rel=self in a different feed (unlikely, but possible). It's also possible for the same feed to switch from having an atom:id with one value, to having a rel=self with the a different value. b) rel=self can change c) rel=self offers no guarantee of uniqueness Unless you can explain how multiple different feeds can be obtained via one URI As I explained on a thread last week, rel=self doesn't necessarily correspond with the address the feed is being served from. Stop making this mistake. Graham
Re: PaceOptionalSummary
Let's forget about Paces for a minute. Does anyone disagree with the principal of recommending publishers include summaries if they have them available, and aren't supplying atom:content? Don't worry about how it might be worded for now, just the principal. Graham
Re: Last Call: 'The Atom Syndication Format' to Proposed Standard
On 8 May 2005, at 4:30 am, Walter Underwood wrote: White space is not particularly meaningful in some of these languages, so we cannot expect them to suddenly pay attention to that just so they can use Atom. There will be plenty of content from other formats with this linguistically meaningless white space. So the idea is that whitespace should not appear at all in certain texts, and you'd like it to be stripped out at the consumer? There are only three possible ways for this to happen: 1) The consumer removes all whitespace, even in western texts 2) The consumer recognizes these languages and removes the whitespace automatically 3) The consumer is told what to do by an attribute (1) is obviously not plausible, but included for completeness. (2) is impractical. (3) is plausible, but may or may not end up being implemented in all consumers, making it kind of useless. I don't see how there's a better solution than texts that shouldn't be shown with whitespace not containing whitespace in the first place, which is what we have. Graham
Re: PaceFeedIdOrSelf
On 10 May 2005, at 2:42 pm, Antone Roundy wrote: Both the proposed text and the text that made it in say that the URI (or IRI) identifies or SHOULD identify the feed. The proposal says that the feed SHOULD be available from that xRI. OK, fair enough. But the other reasons I gave are far more important. Was not self added largely/primarily to enable feed readers that didn't get the information about the IRI from which a feed was retrieved to subscribe to it? Did we not discuss standard behavior when obtaining a feed from a different IRI being automatically switching to the self value when accessing it in the future? See http://www.imc.org/atom-syntax/mail-archive/msg12176.html for example. The model was that the browser downloaded the file, and the OS sent a system event to the feed reader asking it to open the file. If I received such a system event, I'd look for the rel=self in the file and subscribe to that address. This all works without looking at self in feeds that are already subscribed to, which would be entirely separate functionality and (apart from that message) hasn't been discussed on the list, as far as I remember. Graham
Re: Autodiscovery paces
On 10 May 2005, at 3:38 am, Nikolas Coukouma wrote: http://www.intertwingly.net/wiki/pie/PaceAnchorSupport -1 I also don't want to implement it. http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue -1 I mainly don't see the point of changing it. Also, while alternate expressly says the feed corresponds in some way to the content of the current page, feed simply says here is a feed of some kind, and isn't a relationship at all. Graham
Re: Atom 1.0?
On 10 May 2005, at 9:27 pm, Robert Sayre wrote: Walter, that's a good point. How about: Marketing: Atom Technical: Atom (RFC) Around Dave Winer: RFC The only real problem with dropping the version number is making it clear there've been major changes since 0.3. Graham
