Re: Fwd: Atom format interpretation question
James M Snell wrote: If you want to use the text/vnd.IPTC.NewsML media type to identify the type of XML, then you'd have to escape the markup and treat it like text. s/escape/Base64/ s/like text/as binary/ - Sam Ruby
Re: Fwd: Atom format interpretation question
James M Snell wrote: Ahhh... a slight ambiguity presents itself. The treatment of text/ types in RFC 4287 is a bit underspecified. I've always worked off the assumption that text/* types do not require base64 encoding (that's what Abdera expects). On second read, JamesH is right (as were you, originally); I was wrong. I don't see the ambiguity. - James James Holderness wrote: Sam Ruby wrote: James M Snell wrote: If you want to use the text/vnd.IPTC.NewsML media type to identify the type of XML, then you'd have to escape the markup and treat it like text. s/escape/Base64/ s/like text/as binary/ Are you sure? From RFC 4287, section 4.1.3.3: 5. If the value of type begins with text/ (case insensitive), the content of atom:content MUST NOT contain child elements. 6. For all other values of type, the content of atom:content MUST be a valid Base64 encoding, as described in [RFC3548], section 3. In this case the type begins with text/ so surely rule 5 applies, not rule 6. Regards James
Re: AD Evaluation of draft-ietf-atompub-protocol-11
Joe Gregorio wrote: On 12/14/06, Sam Ruby [EMAIL PROTECTED] wrote: I believe I first saw this in a response made by Roy Fielding to an assertion that servers must treat HTTP PUT as a bit-for-bit copy, but I can't immediately find the reference. http://www.imc.org/atom-protocol/mail-archive/msg05425.html That's the one! - Sam Ruby
Re: Atom Entry docs
Tim Bray wrote: Bob Wyman wrote: There is, I think, a compromise position here which will avoid breaking those existing implementations which follow the existing RFC's. co-chair-modeIn case you haven't noticed, the WG is hopelessly split between the new-media-type option and the media-type-parameter option. If a few people were to put up their hands and say yeah what Bob said your co-chairs would probably do a hasty consensus grab./co-chair-mode +1 to what Bob said - Sam Ruby
Re: AD Evaluation of draft-ietf-atompub-protocol-11
Lisa Dusseault wrote: Can a server ever ignore part of an edit and successfully process the rest? Yes. Think of a client that throws in a slew of random link elements with relations my server implementation doesn't understand. Same with foreign markup. The server is in charge. I completely disagree with this. It is way too unpredictable for clients to deal with. Clients are left with the illusion of flexibility -- it *seems* you can use Atom syntax extensions and do creative things that other extended clients can understand -- but in fact the server can alter this at will leaving the client without any control over what it's really publishing. In many cases, the client won't even want the server to store some stripped version of what it POSTed, because it can really change the meaning of some entry to have the server strip some of the content and markup. Imagine removing the start time and location when I'm trying to publish an event entry to what I believe ought to be a calendar feed. Some server changes to submitted documents is of course going to be allowable (edit dates, server-provided IDs, changes which are effectively XML canonicalization) but I believe these need to be limited. The general case, which is how servers deal with unrecognized elements, needs to be severely limited so that the server can either reject the whole request or store as provided. I believe I first saw this in a response made by Roy Fielding to an assertion that servers must treat HTTP PUT as a bit-for-bit copy, but I can't immediately find the reference. In any case: clients must always consider the possibility that the server processes other requests (even internally generated ones) between the time the one the client issued and the next request the server choses to process. Such requests could partially or completely change the representation of the resource. - Sam Ruby
Re: WG Last Call for draft-ietf-atompub-protocol
Paul Hoffman wrote: The WG Last Call will close September 26. Here's a list of Paces that weren't disposed of with the last consensus call: PaceAppEdited PaceAppEdited2 PaceAppModified3 PaceAppVersion PaceCollectionLinkType PaceFixModel PaceLocationPointsToEntry PaceOrderCollectionsByAppModified2 PaceRemoveConnegSuggestionOnServiceDoc PaceRemoveOutOfLineCategoriesFromCategoryDocument PaceRevertTitle PaceSecurityConsiderationsRevised PaceServiceLinkType UseElementsForAppCollectionTitles2 UseElementsForAppCollectionTitles3 - Sam Ruby
Re: Can/Does/Should the FeedValidator catch improperly escaped XHTML?
M. David Peterson wrote: via http://www.oreillynet.com/xml/blog/2006/08/and_the_winner_of_the_best_ind_1.html#comment-75533 There's one other small problem though: they put XHTML as CDATA in html text constructs, while they're supposed to contain HTML 4. And since it's XHTML, they should embed it directly in xhtml constructs... Anthony brings out a good point http://www.oreillynet.com/xml/blog/2006/08/and_the_winner_of_the_best_ind_1.html#comment-75822 , Odd that the validator isn't saying anything about this. Should it, or is this an edge case that can be difficult, at best, to catch? At the moment, the HTML content is passed through the following: http://docs.python.org/lib/module-HTMLParser.html Note that this parser includes a handle_startendtag method, which is not a part of the HTML standard. Given the rather loose nature of HTML, this only tends to catch things like unmatched angle brackets and quotes. Also, there are a number of tools that attempt to produce well-formed XHTML, but don't do so consistently enough to drop the content into an Atom feed in such a manner. - Sam Ruby
Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests
Robert Sayre wrote: I'll file a bug on UFP and I bet you it'll get fixed without a question http://sourceforge.net/tracker/index.php?func=detailaid=1474256group_id=112328atid=661937 - Sam Ruby
Atom ConformanceTests results and feedback
http://planet.intertwingly.net/AtomConformanceTests/ It would be helpful if every entry had a distinct atom:id. And if the tests were valid: http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fplasmasturm.org%2Fattic%2Fatom-tests%2Fxmlbase.atom - Sam Ruby
Re: xml:base in your Atom feed
Antone Roundy wrote: Sam, Funny that this should come up today given the recent discussion on the mailing list--NetNewsWire isn't getting the links in your Atom feed right. There is an off chance that I have been following the list. ;-) - Sam Ruby
Re: xml:base in your Atom feed
Antone Roundy wrote: On Mar 31, 2006, at 4:12 PM, Sam Ruby wrote: Antone Roundy wrote: Sam, Funny that this should come up today given the recent discussion on the mailing list--NetNewsWire isn't getting the links in your Atom feed right. There is an off chance that I have been following the list. ;-) I certainly didn't mean to imply that you weren't--I just wanted to point out what I'm seeing in case you didn't know that this particular feed reader is having this particular problem today. And I thought it might be of interest to the WG to know what NNW is doing given that it's doing something that has been argued against within the last 24 hours. ;-) I don't remember which version of your feed I was subscribed to before--perhaps I wasn't subscribed to the Atom feed and NNW updated my subscription when you redirected to it. So I don't know whether you purposely removed xml:base to see what chaos would ensue, or whether it hasn't been there all along and I just haven't seen the problem since I was subscribed to a different version. As late as this morning, all link/@href attributes in my Atom feed contained absolute URIs. One of the original problems that Atom set out to solve was the desire by people to use relative URIs. Even in their content. In fact, PARTICULARLY in their content. My recent post of Common Feed Errors demonstrate that this demand certainly exists - even in RSS: http://www.intertwingly.net/blog/2006/03/13/Common-Feed-Errors It would be helpful if people were to update: http://intertwingly.net/wiki/pie/XmlBaseConformanceTests - Sam Ruby
Re: xml:base in your Atom feed
A. Pagaltzis wrote:
Sam: is it possible to host the test suites directly on the wiki,
by having pages that consist entirely of verbatim text? Ideally,
the content should be rendered inside the wiki chrome using
`pre` tags, but be downloadable without the chome by way of
adding something like `?display=raw;type=application/atom+xml`
At the moment, the raw text can be obtained with ?action=raw
Of course, that means that the non raw text might look a little weird.
I am comfortable enough with the moin code base that I would be willing
to code up a specific action just for this wiki that strips leading {{{
and trailing }}} and then delivers the results raw, with the appropriate
mime type.
How does ?action=atomtest sound?
- Sam Ruby
Re: IE7 Atom Handling (was RE: Link rel attribute stylesheet)
David Powell wrote: 03. atom:published While atom:updated is converted to pubDate, atom:published is kept as atom:published; except, the date format is converted to RFC822 format. I think that the date format should be kept as-is in ISO8601-style format. Why is atom:updated converted to pubDate? If any atom date is converted to pubDate, why isn't it atom:published? - Sam Ruby
Re: IE7 Atom Handling (was RE: Link rel attribute stylesheet)
Sean Lyndersay wrote: Thanks James. I’ve filed bugs in our bug tracking database for each of the issues that came up in the feed validator (except for flagging /atom:*/ items, since these are a correct use of RSS 2.0 extension namespaces). Re the flagging of atom: elements: this was indeed a bug in the Feed Validator. The Feed Validator was incorrectly flagging the use of atom:author elements at the channel level and atom:link elements at the item level. A test case has been expanded to include these elements, and these problems have been corrected. The fix should be deployed online in a matter of hours. - Sam Ruby
Re: Fwd: [rss-public] Microsoft Feeds API Enclosure Test
Sean Lyndersay wrote: As an format that is not intended for publishing on the web, but which is really a contract between the platform and the clients of the platform, the native format we use is not really required to be pure RSS 2.0. Sean, I'm not sure what you are looking for. If the position you find yourself in is that you are feature complete, the format you have selected you expect to support in perpetuity, you have baked silent data loss right into the Windows platform, but you will accept bug reports, then simply realize that bug reports can be created at will. If, instead, the position is that you have an internal data model which is open for discussion, then we can have a discussion. If you look on the web, you will find plenty of RSS 2.0 feeds that contain small bits of HTML markup -- things like bold words or italics -- in titles. You will find feeds with multiple enclosures. You will find feeds with relative references. The RSS 2.0 spec doesn't disallow any of these, nor does it specify how such things are to be interpreted. Even so, such things are out there. And they either need to be in your model, or you have either data loss or data corruption. You seem to think that you have picked RSS 2.0. If you take a look at the current food fight regarding the RSS Advisory Board, you would realize that RSS 2.0 is frozen. There are only two paths forward. Creating new formats with new names, or the use of extensions. The newly reconsituted RSS Advisory Board thought that it could change RSS by providing a small number of much needed clarifications. They were wrong. By changing what the description element is, you are changing RSS 2.0. Call what you are creating a new format. Or use a different element, in a namespace. Perhaps atom:summary would do. Or you could create your own. - Sam Ruby
Re: atom:updated handling
Bob Wyman wrote: Phil Ringnalda wrote: Patches that will make that more clear are welcome. The warning message that Phil points to says in part: (at: http://feedvalidator.org/docs/warning/DuplicateUpdated.html) For example, it would be generally inappropriate for a publishing system to apply the same timestamp to several entries which were published during the course of a single day. Of course, this leads one to wonder if it might be appropriate to apply the same timestamp to several entries if they were published during the course of multiple days... It would make a great deal more sense to say something like: It would not be appropriate to apply the same timestamp to several entries unless they were published simultaneously. As you might imagine, given the context of syndication, the Feed Validator has the potential for being in the center of controversy. One of the reasons why it has avoided being such is that I try to rely directly on the wording from the spec whenever possible. http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.3.3 - Sam Ruby
Re: Browser behaviour
Tim Bray wrote: On Jan 30, 2006, at 8:23 AM, James M Snell wrote: +1. Serving atom up at application/xml is perfectly acceptable It is *not*. Atom has a registered Internet media type (application/ atom+xml); using anything else is a bug. -Tim I'm not sure I would stand on principle for that one if I were you. Xhtml also has a registered Internet media type (application/xhtml+xml), but many people (grin) serve up their xhtml pages as text/html. I'd like to take a survey of what web browsers will accept and what they indicate they prefer. http://www.intertwingly.net/wiki/pie/AcceptHeaders Based on the results, I will gladly start sending my feed at application/atom+xml to those browsers that *don't* indicate a preference for application/xml. As well as make a change to the Feed Validator to send such a header itself. - Sam Ruby
Re: Atom features support in readers?
Stephane Bortzmeyer wrote: Is there somewhere a comprehensive survey of the current level of support in readers, with details for each feature, specially the most Atom-specific? I tested content=xhtml support for several readers and none does it properly. I would like to have information for other readers. (Remember also the discussion here about the support of updated.) Some results can be found here: http://www.intertwingly.net/wiki/pie/ConformanceTests Please feel free to add more. - Sam Ruby
Re: AtomPubIssuesList for 2005/11/30
Robert Sayre wrote: On 11/30/05, Sam Ruby [EMAIL PROTECTED] wrote: Robert Sayre wrote: I noticed you moved PaceFeedsNotCollections and PaceSimpleIntroduction into the Closed section. http://www.imc.org/atom-protocol/mail-archive/msg03545.html And, unless I misinterpreted, both Paul and Tim confirmed via email and/or IM that this was their intent; That message concerned PaceServiceDescription, which has been moved to Recommended For Closure. No argument there. PaceFeedsNotCollections and PaceSimpleIntroduction were moved directly to Closed. Once again, I'm not arguing, just asking that the WG's decision be documented explicitly. Both were moved from the 'not yet taken up' to the 'currently under discussion' section the last cycle: http://www.imc.org/atom-syntax/mail-archive/msg17547.html Re-reading Tim's Search for Introspection Consensus and Paul's Tallying the survey, I now have serious doubts that they this covers PaceSimpleIntroduction, so I'm moving that back to revisit. If it turns out that that PaceFeedsNotCollections was not included in what Tim was referring to by introspection via feeds/links, then I'll move this one back too. - Sam Ruby
Re: AtomPubIssuesList for 2005/11/30
Robert Sayre wrote: On 11/30/05, Sam Ruby [EMAIL PROTECTED] wrote: Sceduling the remaining Introspection/Collection paces as well as the ones that are under active discussion anyway: Additionally, I'm recommending the following for closure: Hi Sam! I noticed you moved PaceFeedsNotCollections and PaceSimpleIntroduction into the Closed section. That certainly seems reasonable to me, since they received opposition and little support. However, the record of their transition needs to be documented on the mailing list by the secretary or chairs. I did this based on the following: http://www.imc.org/atom-protocol/mail-archive/msg03545.html And, unless I misinterpreted, both Paul and Tim confirmed via email and/or IM that this was their intent; that being said, having one or both of them making their intentions more explicit on the mailing list wouldn't hurt. - Sam Ruby
AtomPubIssuesList for 2005/09/05
A lot of work is going on in the area of collections - in at least two different directions. Depending on which direction we select, a number of existing paces may become obsolete. Accordingly, I'm scheduling: PaceAppDocuments2 PaceSimplifyCollections And the two paces prereqed by PaceAppDocuments2: PaceAppDocuments PaceCollectionClasses As always, discussion of these paces should occur on the atom protocol list, with a subject line identifying which pace you are expressing an opinion on. - Sam Ruby
Re: xml:base abuse
Sjoerd Visscher wrote: Sam Ruby wrote: URI(doc) = http://www.w3future.com/weblog/rss.xml?notransform xml:base = http://w3future.com/weblog/rss.xml?notransform Ah, ok, I missed that. (Just to be sure, you added www yourself, or is there a link to the feed somewhere with www in it?) Your feed is available from both of the URI's mentioned above. The tinyurl quoted above is based on passing the first one to the feed validator. Oh, this is actually interesting. I send a 301 when you use www.w3future.com. It looks like this is handled transparently by your http library, giving you the file at w3future.com. In that case it should be possible to request the actual uri that is used to get the file. Fixed. And then there's also the Content-Location header, which sets the base URI. This is used with content negotiation. F.e. (I haven't actually implemented this) if you would send a request to http://w3future.com/weblog/ with the header Accept: application/atom+xml I could send you the atom file with this header: Content-Location: http://w3future.com/weblog/rss.xml?notransform Afaik this is how the HTTP spec suggest to implement content negotiation. Then the value of Content-Location should be considered to be the uri of the document. I now check for content-location too. - Sam Ruby
Re: If you want Fat Pings just use Atom!
A. Pagaltzis wrote: * Bob Wyman [EMAIL PROTECTED] [2005-08-22 01:05]: What do you think? Is there any conceptual problem with streaming basic Atom over TCP/IP, HTTP continuous sessions (probably using chunked content) etc.? I wonder how you would make sure that the document is well-formed. Since the stream never actually ends and there is no way for a client to signal an intent to close the connection, the feed at the top would never actually be accompanied by a /feed at the bottom. If you accept that the stream can never be a complete well-formed document, is there any reason not to simply send a stream of concatenated Atom Entry Documents? That would seem like the absolute simplest solution. I think the keyword in the above is complete. SAX is a popular API for dealing with streaming XML (and there are a number of pull parsing APIs too). It makes individual elements available to your application as they are read. If at any point, the SAX parser determines that your feed is not well formed, it throws an error at that point. With a HTTP client library and SAX, the absolute simplest solution is what Bob is describing: a single document that never completes. Note that if your application were to discard all the data it receives before it encouters the first entry, the stream from there on out would be identical. - Sam Ruby
Re: If you want Fat Pings just use Atom!
Joe Gregorio wrote: Why not POST the Atom Entry, ala the Atom Publishing Protocol? Essentially, LiveJournal is making this data available to anybody who wishes to access it, without any need to register or to invent a unique API. I can, and have, accessed the LiveJournal stream from behind both a firewall and a NAT device. Doing so requires the client to initiate the request. Therefore, if you really wanted to turn this around, the client would need to initiate a POST, and the server would need to return the Fat Pings as the response. I talked to Brad - in fact, I had independently made the same suggestion that Bob did. Brad indicated that if there were clients with different requirements, he was amenable to accommodating each - endpoints are cheap. - Sam Ruby
Re: xml:base abuse
Sjoerd Visscher wrote: Sam Ruby wrote: Apparently, consuming tools are welcome to aggressively substitute references to the enclosing parent document of any element for any references that, when resolved according to xml:base, differ from that xml:base only in ways that deal with normalization and fragment identifiers. This can only cause confusion if the xml:base in effect differs from original xml:base of the document (i.e., the URI used to retrieve the document in the first place) in ways other than the fragment identifier. You've nailed it. Sjoerd, I'd be interested in your comments on this: http://tinyurl.com/9o6y2 - Sam Ruby
Re: xml:base abuse
Robert Sayre wrote: On 8/15/05, Sjoerd Visscher [EMAIL PROTECTED] wrote: Yes, it's a known bug. https://bugzilla.mozilla.org/show_bug.cgi?id=275689 Well, it's not clear from that bug that any Mozilla committers feel it's wise to fix. Even so, they seem to be leaning towards patching html:a as a special case, in the event that they do anything. I'll agree that this should be a warning, and perhaps write something that willcome back to haunt me--Atom makes a point of leaning many established specifications. It's unwise to lean on those specs in the corner cases where they diverge from existing implementations, and a warning in the feedvalidator is justified in such cases. What I see occurring here is implementations dealing with the attendent confusions that their users face as the result of an unclear specification of a corner case in a spec. After all this discussion, I am *still* unclear as to where this corner case is. Let me try again. Apparently, consuming tools are welcome to aggressively substitute references to the enclosing parent document of any element for any references that, when resolved according to xml:base, differ from that xml:base only in ways that deal with normalization and fragment identifiers. This can only cause confusion if the xml:base in effect differs from original xml:base of the document (i.e., the URI used to retrieve the document in the first place) in ways other than the fragment identifier. Sjoerd: is this your understanding? Note that I'm sidestepping all questions about who is right or wrong. Different implementations may chose different strategies on how aggressive they wish to be. If my understanding is correct, then I will agree that it is unwise for feeds to express URIs that some consumers will interpret in one way, and others will interpret in an other way; therefore a warning is warranted. If my understanding is correct, I can produce test cases (and would welcome any contributions in this area), and fix the feed validator. The recommendations produced by the feed validator will focus on the areas where the user is most likely to stumble into this problem. It seems to me that the largest problem area is at the feed level, and the recommendation will be to either make xml:base at the feed level match the URI from which the feed was loaded, or (paradoxically enough) to reference a resource that you are unlikely to directly reference later in the document. Referencing a parent directory of any given document is OK, what's important is that it isn't the document itself. And to include an example that matches what Sjoerd's feed (and now Tim's feed) now do. Fair enough? - Sam Ruby
Re: xml:base abuse
Sjoerd Visscher wrote: Sam Ruby wrote: Apparently, consuming tools are welcome to aggressively substitute references to the enclosing parent document of any element for any references that, when resolved according to xml:base, differ from that xml:base only in ways that deal with normalization and fragment identifiers. This can only cause confusion if the xml:base in effect differs from original xml:base of the document (i.e., the URI used to retrieve the document in the first place) in ways other than the fragment identifier. You've nailed it. Cool. Took me long enough. Note that I'm sidestepping all questions about who is right or wrong. I totally agree, there is no right or wrong here. The established usage of a base URI is so different from what Roy is saying that he shouldn't have changed the RFC in such a way. (The RFC is even an Internet Standard, defined as a specification that is stable and well-understood.) I'm sure that we can find established usages where the consuming tool has various degrees of agressiveness. Pure speculation on my part, but now that I have been able to see how limited in scope this issue is, I can see where spec authors might have had trouble outlawing one behavior or another, and decided that publishing a spec within a reasonable timeframe was of greater value than resolving this issue. The recommendations produced by the feed validator will focus on the areas where the user is most likely to stumble into this problem. It seems to me that the largest problem area is at the feed level, and the recommendation will be to either make xml:base at the feed level match the URI from which the feed was loaded, or (paradoxically enough) to reference a resource that you are unlikely to directly reference later in the document. Referencing a parent directory of any given document is OK, what's important is that it isn't the document itself. Yes, although I wonder how you would test for unlikely to directly reference later. I will only test for actual references that meet the criteria described at the top of this note. When I encounter such a condition, I will emit a warning containing a one line message accompanied by a link. That link will take the user to a web page that repeats the one line message, provides an explation of that message (probably close to what I said at the top of the page), provide a recommendation (probably close to what I said in the second paragraph above this one), and a link to the feedvalidator mailing list. - Sam Ruby
Re: xml:base abuse
Sjoerd Visscher wrote: Let me show you some pseudo-code that implements how to dereference an atom link according to rfc3986: dereference(linkElement) = baseURI = linkElement.baseURI linkURI = makeAbsolute(linkElement.href, baseURI) if stripFragmentID(linkURI) == stripFragmentID(baseURI) then return linkElement.ownerDocument else return loadDocument(linkURI) You'll see the problem when you pass the link element of Tim Brays feed. Focusing on the link href=/ in Tim's existing feed, it seems to me that Tim intended to express http://www.tbray.org/ongoing/. How you interpret the spec is that this will actually resolve to http://www.tbray.org/ongoing/ongoing.atom. Am I correct so far? If so, what would happen if he replaced this with link href=//? linkURI would still resolve to the same value as baseURI. Do you interpret the spec is that this will also resolve to http://www.tbray.org/ongoing/ongoing.atom? How about link href=.//? I guess that would depend on what the meaning of == is. - - - I am quite willing to add feed validator warnings for edge cases where reasonable professionals might have differing opinions of how to read the specification, particularly if there is no compelling use case for use of the feature. Can we agree that empty //atom:link/@href values, or //atom:link/@href values that consist entirely of a fragment are problematic? - Sam Ruby
AtomPubIssuesList for 2005/08/15
The biggest issue yet to be solved is categorizing draft documents. Accordingly, I'm scheduling the following, each of which either addresses the specific issue, or the more general one: PaceCollectionControl PaceCollectionProcess PaceSimpleDraft Discussion of these paces should occur on the atom protocol list, with a subject line identifying which pace you are expressing an opinion on. I'm also marking for closure: PaceCategorize PaceRenameUriElement The former seems to have been withdrawn, and the latter is neither a showstopper or a clarification/bug fix to the format document. In either case speak now if you feel otherwise. - Sam Ruby
Re: atom:id spec bug
Graham wrote: 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? +1 - Sam Ruby
Re: spec bug: can we fix for draft-11?
Tim Bray wrote: On Aug 4, 2005, at 1:04 PM, Sam Ruby wrote: Tim Bray wrote: I'm getting increasingly grumpy and just fail is looking better and better. The current normative text, The element's content MUST be an IRI, is clear and simple and supported by other well-understood normative text, supported by lots of interoperable software, that make the meanings of element, content, and IRI not really open to intelligent dispute. I claim that text enjoyed strong, not rough, consensus support from the WG. I believe that the term content is open to intelligent dispute. Apparently the authors of RFC3470/BCP70 believe so too. Could you reference that? It seems to me that the guidance we should take from 3470 is from section 4.16, which seems to me to make it clear that *we* should make it clear that id http://example.com/foo /id is an error and nothing but an error. -Tim My point was simply that *we* should make it clear. Either of the texts that Rob proposed [1] is sufficient for my purposes. You appear to have a strong preference for #2, and a strong aversion to #1. I haven't heard anybody opposed to #2. This seems to me to be to be a sufficient basis for the chairs to declare (re-affirm?) consensus on this matter. If either is adopted, I will simply add a slew of tests to [2], ensure that they pass, and commit the change. - Sam Ruby [1] http://www.imc.org/atom-syntax/mail-archive/msg16616.html [2] http://feedvalidator.org/testcases/atom/2/
Re: spec bug: can we fix for draft-11?
Tim Bray wrote: I'm getting increasingly grumpy and just fail is looking better and better. The current normative text, The element's content MUST be an IRI, is clear and simple and supported by other well-understood normative text, supported by lots of interoperable software, that make the meanings of element, content, and IRI not really open to intelligent dispute. I claim that text enjoyed strong, not rough, consensus support from the WG. I believe that the term content is open to intelligent dispute. Apparently the authors of RFC3470/BCP70 believe so too. I won't dispute your read on the consensus of the working group, but I would like to request that *SOME* language be present in the spec that makes this clear. - Sam Ruby
Re: spec bug: can we fix for draft-11?
Julian Reschke wrote:
James Cerra wrote:
Ian Davis wrote:
Graham wrote:
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).
Leading and trailing whitespace should be stripped from the content
of an atom:id element.
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.
+1. But Sam Ruby's first draft at [1] demostrated more than just
atom:id. (He
changed it now so that the examples don't have white space showing!
lol!) They
also included things like:
id
http://example.com/
/id
updated
2003-12-13T18:30:02Z
/updated
Neither of those are strictly legal, since white space is illegal in
both IRI
and RFC 3339 (dates) I think. However they are legal with the Relax
NG grammer
used.
Why would they be legal with the RNG grammar
From http://www.w3.org/TR/xmlschema-2/#dt-whiteSpace:
For all ·atomic· datatypes other than string (and types ·derived· by
·restriction· from it) the value of whiteSpace is collapse and
cannot be changed by a schema author; for string the value of
whiteSpace is preserve; for any type ·derived· by ·restriction· from
string the value of whiteSpace can be any of the three legal values.
That being said, the RNC grammar for atom contains:
atomId = element atom:id {
atomCommonAttributes,
(atomUri)
}
# Unconstrained; it's not entirely clear how IRI fit into
# xsd:anyURI so let's not try to constrain it here
atomUri = text
- Sam Ruby
Re: spec bug: can we fix for draft-11?
Graham wrote: 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. I have put code out in the wild based on the assumption that whitespace is not significant. One or more of us have a bug, and potentially the spec does too. Note: the code in the feedvalidators consists entirely of a single line, and that line was put in there intentionally, and test cases were coded to ensure that this code behaved as intended. Note: from an XML point of view, the following are all distinct: idhttp://example.com/id id![CDATA[http://example.com]]/id id http://example.com /id However, from the point of view of a tool that expects a xsd:anyURI, they are the same. I'm not yet sure what the right thing to do here is, but lets to do the right thing. Even if we decide that whitespace is not significant, I do believe that having the feedvalidator issue a warning in such cases is appropriate. - Sam Ruby
Re: spec bug: can we fix for draft-11?
Julian Reschke wrote: Robert Sayre wrote: On 8/2/05, James Cerra [EMAIL PROTECTED] wrote: Neither of those are strictly legal, since white space is illegal in both IRI and RFC 3339 (dates) I think. However they are legal with the Relax NG grammer used. Yes, they are. Relax NG regex matching strips leading and trailing whitespace. Atom Processors will do the same, so we should fix it. Comparison operations MUST be based solely on the IRI character strings, and the URI specs have always suggested that you should strip leading and trailing space. Robert Sayre Me confused. In atomDateConstruct = atomCommonAttributes, xsd:dateTime (http://www.atompub.org/2005/07/11/draft-ietf-atompub-format-10.html#rfc.section.3.3), how exactly does this allow whitespace around the xsd:datetime value??? Take a look at sections 3.2.7.6 and 4.3.6 of XML Schema Part 2: Datatypes Second Edition, W3C Recommendation 28 October 2004. - Sam Ruby
Re: spec bug: can we fix for draft-11?
A. Pagaltzis wrote: At the very least, the normalization procedure that the spec RECOMMENDS should contain language about stripping surrounding whitespace. I too would like to see that added to the recommended normalization rules in section 4.2.6. That would make my job easier if somebody were to challenge why I produced a warning in such a situation. As it stands now, the spec does NOT clearly outlaw leading and trailing whitespace from ids, and DOES require anybody the string to be kept character by character equivalent whenever an entry is relocated, migrated, syndicated, republished, exported or imported. If Graham was truly serious about wanting to do his part[1] to ensure that atom:id is implemented properly, I would expect any atom:ids that he mints from here on out to contain leading and trailing spaces, tabs, and newlines (in a variety of Mac, DOS, and Unix styles). But I wouldn't recommend it. To me, doing so would be akin to mailing fragile equipment and paying for insurance, in the hopes of getting the opportunity to express indignation at the post office. - Sam Ruby [1] http://www.imc.org/atom-syntax/mail-archive/msg16243.html
Re: Proposed changes for format-11
Eric Scheid wrote: On 1/8/05 5:39 PM, David Powell [EMAIL PROTECTED] wrote: This specification does not place any restrictions on what elements may be used as Metadata Extensions, but the RelaxNG grammar explicitly excludes elements in the Atom namespace. The Atom namespace is reserved for future forwards-compatable revisions of Atom. I'm not sure I like this paragraph. It starts by saying that it places no restriction on the elements, then mentions the RelaxNG, then in the final sentence, it says that actually there is a restriction after all. I don't know - perhaps I'm not reading it right, but it sounds contradictory. It would make more sense to me if everything was dropped except the last sentence. I agree, especially since elsewhere the RelaxNG is noted to be Informative, not Normative. This paragraph appears to be expressing two separate thoughts. Perhaps the solution is to separate the thoughts into separate paragraphs. Perhaps the following could be added to section 6.2: The Atom namespace is reserved for future forwards-compatable revisions of Atom. Which would enable the text in appendix B to simply state: The RelaxNG grammar explicitly excludes elements in the Atom namespace which are not defined in this revision of the specification. - Sam Ruby
Introduction to The Atom Syndication Format
http://www.atomenabled.org/developers/syndication/ Feedback welcome. - Sam Ruby
Re: Atom 1.0 xml:base/URI funnies
Sjoerd Visscher wrote: Tim Bray wrote: On Jul 16, 2005, at 1:28 PM, Sam Ruby wrote: I didn't realize that path-empty was a valid URI-reference. Yeah, it means here. And that's why you can't use it as a reference to your site. To quote from RFC 3986: When a URI reference refers to a URI that is, aside from its fragment component (if any), identical to the base URI (Section 5.1), that reference is called a same-document reference. The most frequent examples of same-document references are relative references that are empty or include only the number sign (#) separator followed by a fragment identifier. When a same-document reference is dereferenced for a retrieval action, the target of that reference is defined to be within the same entity (representation, document, or message) as the reference; therefore, a dereference should not result in a new retrieval action. So, link href='' / links to the atom file (as currently in memory), not your site. This is how the feedvalidator evolves. It is highly unlikely that here is what a person intends as an alternate. Instead, something like the following might be more appropriate. link href=./ On the other hand, here is *exactly* what a person should be intending as self. link href= rel=self/ ... however, that completely and utterly misses the point of the use case that rel=self was intended for (subscription given only the content of a feed), UNLESS xml:base is explicitly specified and resolves to a fully qualified URI. Both of these cases merit warnings, IMHO. Please consider updating http://intertwingly.net/wiki/pie/FormatTests with these and any other situations worth warning people about. - Sam Ruby
Re: Atom 1.0 xml:base/URI funnies
Sjoerd Visscher wrote: Tim Bray wrote: On Jul 16, 2005, at 1:28 PM, Sam Ruby wrote: I didn't realize that path-empty was a valid URI-reference. Yeah, it means here. And that's why you can't use it as a reference to your site. To quote from RFC 3986: When a URI reference refers to a URI that is, aside from its fragment component (if any), identical to the base URI (Section 5.1), that reference is called a same-document reference. The most frequent examples of same-document references are relative references that are empty or include only the number sign (#) separator followed by a fragment identifier. When a same-document reference is dereferenced for a retrieval action, the target of that reference is defined to be within the same entity (representation, document, or message) as the reference; therefore, a dereference should not result in a new retrieval action. So, link href='' / links to the atom file (as currently in memory), not your site. Upon further reading of 3986, I'm convinced that Tim's current feed is correct. Base URI defaults to the Retrieval URI. This gives rise to the common use case of same-document references. However, Base URI Embedded in Content. In XML documents, this takes the form of xml:base attribute values. This is the case in Tim's feed. - Sam Ruby
Re: Atom 1.0 xml:base/URI funnies
Tim Bray wrote: I got an email last night from a well known syndication implementor pointing out an obvious bug in my Atom feed. The feed's valid, but the stuff in content was full of relative URIs which were broken because I'd borked the xml:base. So I went through the code and got the xml:base right and ruthlessly pruned all the pointers. The feed looks a little weird and it's giving the (pre-alpha) validator a heartburn, but I sort of think it's right. I also think it's good practice. Check it out: feed xmlns='http://www.w3.org/2005/Atom' xml:base='http://www.tbray.org/ongoing/' xml:lang='en-us' titleongoing/title link href='' / link rel='self' href='ongoing.atom' / logorsslogo.jpg/logo icon/favicon.ico/icon I agree that relative URIs are a good practice. I didn't realize that path-empty was a valid URI-reference. Looks like another test case to write. ;-) - - - While it clearly shouldn't be the default behavior, longer term (i.e., sometime well after basic Atom 1.0 support is more complete), how much value do you think that there would be value in an option to attempt to verify all potentially dereferencable URIs resolve to accessible resources? - Sam Ruby
Re: Media extensions
Danny Ayers wrote: On 7/16/05, A. Pagaltzis [EMAIL PROTECTED] wrote: * James M Snell [EMAIL PROTECTED] [2005-07-16 20:05]: If the community can drive a viable solution without the overhead of a formalized standardization process, it will work out best for everyone and the anti-formal-standards crowd will have far less to complain about or will at least be able to devote more time to bashing atom ;-) Yahoo!'s approach did seem to work very well without any formal process, effectively just a mailing list and editor. But then Apple came along... ... at which point, I would think that it should be painfully obvious to all that that which did seem to work very well without any formal process, isn't going to work out very well long term. While I don't believe that *every* extension needs to the overhead of a formalized standardization process, I do believe that there is enough interest in *this* extension that this particular effort would benefit from a wider set of participants. Question: can anybody here quantify the overhead of the IETF standardization process? While I certainly would label some of the last few weeks overhead, everything else I attribute to the impact of allowing and enabling a wider set of participation. Yes, developing specs up to Atom 0.3 was much easier when Mark, Joe, I, and few others could just listen to feedback on mailing lists, blogs, and wikis, and do what we thought was best. But Atom 1.0 is much better. Much. My $0.02. - Sam Ruby
Re: FormatTests
Graham wrote: Why does the validator apparently fail outright when SHOULD level requirements are ignored? This seems unnecessary in light of having a spec where conformance levels are clearly defined. Can you be more specific? Perhaps this will help: FormatTests documents my intent. If you see something there that is wrong, by all means, go fix it. What you see with the current validator in terms of Atom 1.0 support is what I was able to cobble together on a plane ride out; and I'm taking a red-eye back tonight. I expect this to be rapidly corrected over the next few days. When I feel that the feedvalidator is anywhere near ready to be considered seriously for Atom 1.0 feeds, I'll post something on my weblog. - Sam Ruby
Re: Old application/atom+xml issues
Bill de hÓra wrote: Mark Baker wrote: IMO, it matters not that no spec prescribes the use of this media type for Atom 0.3 feeds. What matters is whether it's in use today, which we seem to agree is the case. This seems an important piece of information that implementors should know, which is my motivation for asking that it be called out in the interoperability considerations section of the template. Something like; Interoperability considerations: Some existing agents and feeds that support the Atom 0.3 specification, make use of this media type despite Atom 0.3 not being compatible with Atom 1.0. In the spirit of that point about 0.3 being served with the media type being an interop issue - what are the behaviors which will lead to interoperation? The above text is only leads one to ask and I should do what here? and doesn't say anything useful about what to do. I'll also point out that there are atom 0.3 feeds being served with a mime type of text/html. And undoubtably there will be atom 1.0 feeds so served. The most we can do is to say that such things are invalid, and to work with the producers to correct this. The majority of the existing atom 0.3 feeds are produced by a relatively few producers. I am confident that these producers will convert over quickly. I am also committed to getting the word out quickly that atom 0.3 feeds are not to be considered valid. In particular, I plan to update the feedvalidator to note this as a problem (first as a warning, and later I will change this to an error). - Sam Ruby
Re: Old application/atom+xml issues
Robert Sayre wrote: So, -1 to mentioning Atom 0.3 at all. I agree with Robert. Note how Atom 0.2 isn't a problem at all... we can (and will) do the same thing with Atom 0.3. - Sam Ruby
FormatTests
http://www.intertwingly.net/wiki/pie/FormatTests I've taken a pass at enumerating the test cases required to validate Atom 1.0, based on the presumption that things are not going to change too drastically from draft-ietf-atompub-format-09. Undoubtedly there are typos, bugs, omissions, and there might even be an occasion or two where I have been overzealous. My experience has been that this is only a starter set at best, as the set of possible errors that people will attempt is well beyond anything that one can possibly anticipate. Corrections welcome. - Sam Ruby
Re: Polling Sucks! (was RE: Atom feed synchronization)
Joe Gregorio wrote: On 6/17/05, Sam Ruby [EMAIL PROTECTED] wrote: P.S. Why is this on atom-sytax? Is there a concrete proposal we are talking about here? Is there likely to be? Were you expecting [atom-syntax] to vanish in a puff of smoke once we have a couple RFCs under our belt? Given the technology, and the participants, I would expect [atom-syntax] to have the longevity of [xml-dev]. Silly me. And here I thought it fertile grounds for a protocol discussion. Carry on, then. - Sam Ruby
Re: Polling Sucks! (was RE: Atom feed synchronization)
Joe Gregorio wrote: On 6/17/05, Bob Wyman [EMAIL PROTECTED] wrote: Joe Gregorio wrote: The one thing missing from the analysis is the overhead, and practicality, of switching protocols (HTTP to XMPP). I'm not aware of anything that might be called overhead. I was referring to switching both the client and server from running HTTP to running XMPP. That may not be practical or even possible for some people. Yes, I understand that you run this right now. Yes, I understand that you run a business doing this right now. Yes, I agree that your solution is one way to solve the problem. Do you agree that 99.99% of all syndication is done via HTTP today and also offering an HTTP based solution would be of value? Joe, I'd be careful with how you structure this argument. It could be applied in a different context, for example: Do you agree that 99.99% of all syndication is done via HTTP GET and POST today and offering a solution based only on these two verbs would be of value? One can go down this path and cater to the least common denominator always, or one can say that perhaps MIDP 1.0 phones are not particularly well adapted to perform complex editing tasks beyond simple GET and POST. Perhaps HTTP is suited to a wide, but not universal, range of applications dealing with relatively coarse and relatively infrequently updated content; and XMPP is well suited to a different -- always on, firehose -- set of applications, with a wide overlap between the two. And perhaps they could be combined. I could see a future where there was a feedmesh backbone with nodes exchanging data via XMPP, serving content out to the rest of the universe via HTTP. - Sam Ruby P.S. Why is this on atom-sytax? Is there a concrete proposal we are talking about here? Is there likely to be?
Re: some xmlns:atom tomfoolery
Eric Scheid wrote: An Atom Entry can have XML content, right... Consider this example: feed xmlns=http://...atom; ... entry titlethe minimal Atom Entry/title summaryA minimal entry has only .../summary content type=application/atom+xml entry ... /entry /content /entry /feed Entirely legal, but who wants to bet the feed validator throws a fit ;-) I'll take that bet. - Sam Ruby
Re: How is Atom superior to RSS?
Bob Wyman wrote: Ill be making a presentation on Tuesday which will include a slide on how Atom improves on RSS. If you have any thoughts on this subject, I would appreciate hearing them Much of the following is still relevant: http://intertwingly.net/slides/2003/xmlconf/ I'm not certain what topic your presentation is supposed to cover, but hopefully there is room to mention the protocol. - Sam Ruby
Re: How is Atom superior to RSS?
Bob Wyman wrote: This has been an experiment... I've got lots of thoughts on why Atom is an improvement over RSS but I am constantly amazed that people are able to continue making the claim that Atom offers little that RSS doesn't already support. Certainly, Winer and the Microsoft crowd make that claim regularly. I've often wondered why people don't see the really important differences between these two. To a certain extent, the answer comes in the replies I've received to my posting. i.e. Not even those most familiar with Atom can present a decent list of clear advantages -- even though they undoubtedly know them. Yes, we all know the advantages of requiring unique atom:id values, writing less ambiguous documentation, etc. However, I wonder why advances like the following don't get more recognition (note: this is not a complete list.) 1. Explicit support for xml:lang rather than the silly language/ tag of RSS V2.0. While your effort to create a concise list is very much appreciated, I would recommend avoiding terms like silly. 2. Explicit support, in the core, for digital signatures and encryption. 3. Atom Entry documents. Thus, support for the protocol as well as for push delivery of Atom feeds via Atom over XMPP and other such protocols. (i.e. Atom is designed to enable a push future rather than only working in the legacy pull-only world of RSS) 4. Atom:source elements which provide robust support, in the core, for attribution on entries that have been copied from one feed to another and for preservation of important feed metadata in copied entries. Atom's source element makes it a superior format for delivering search results, for constructing feeds which aggregate entries from multiple sources, and for push applications. 5. Support for XML content types rather than being limited to RSS's HTML content type. It isn't even clear what RSS's content type is. Particularly for title. Even for RSS 1.0. 6. Explicit support for remote content. We all worked hard in getting these new capabilities and others like them into Atom and properly defined. Why aren't these things given more press and attention? They are significant improvements over RSS that will have profound impact on our ability to build better applications for our users. Add atom:updated solves exactly this problem: http://www.25hoursaday.com/weblog/CommentView.aspx?guid=4c8d83e9-bc7e-432d-b5b2-07965bd959ad Add multiple enclosures. http://weblog.burningbird.net/archives/2005/05/03/feeds-fixes/ Add relative URIs: http://intertwingly.net/slides/2003/xmlconf/34.html Add clear distinction between summary and content: http://www.imc.org/atom-syntax/mail-archive/msg15208.html http://www.imc.org/atom-syntax/mail-archive/msg15266.html - Sam Ruby
Re: Consensus call on last raft of issues
Tim Bray wrote: On May 18, 2005, at 6:19 PM, Sam Ruby wrote: Isn't that redundant? From PaceOptionalSummary: Yup. Think we got that covered. -Tim Off list, Robert pointed out to me that that the spec text I cited didn't cover empty summaries. He's right. - Sam Ruby
Re: Compulsory feed ID?
Tim Bray wrote: On May 18, 2005, at 9:11 AM, Sam Ruby wrote: There seemed to be consensus that feeds needed something to identify them. What there wasn't consensus on is which element should be that identifier. The solution selected was to make none of the identifiers required - something I don't think has much support, and furthermore creates problems with the ability to cite a source. Paul and I talked this over, and while we're not sure (the email trail was confusing) Sam may be right; so let's find out. Note that it seems pretty clear that the cost of requiring atom:id is nearly zero, since anyone who's generating Atom has to have an ID generator around for entries. So, let's find out if Sam is right: Permit me to provide some more background. I *think* that there is some desire that if the SAME entry appears in multiple places (say, TheServerSide, Java.net, Artima, etc.) that it not appear multiple times. This specific example was called out here: http://www.tbray.org/ongoing/When/200x/2005/04/03/Atom-Now#p-1 I appologize for referencing something outside of the mailing list, and if the item I cited does not represent the consensus of the working group, then the following text should be removed from PaceDuplicateIDs: If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they represent the same entry - - - If, however, this above is what we desire (and I certainly support it), let's see what Bob's objection was: http://www.imc.org/atom-syntax/mail-archive/msg14470.html In that, he said: The problem is, once again, that prohibiting duplicate ids provides an easy to use attack vector for those wishing to effectively erase entries written by another author. Now, lets take a look again at that text from PaceDuplicateIDs: If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they represent the same entry. It seems to me that this does not solve the problem that Bob described. More specifically, if pubsub were to republish data from TheServerSide, Artima, or other places, then the erasure that Bob fears would come to pass. What's most puzzling is that it appears that PaceDuplicate IDs was specifically written in response to Bob's concerns: http://www.imc.org/atom-syntax/mail-archive/msg14731.html What is missing in all this is the following, again from Bob's original statement of the problem: Graham Park has proposed that we loosen the existing language to permit duplicate ids in the case where the entries have atom:source elements which identify different URIs in self links. I support this compromise and believe it should be supported by the WG and incorporated into the Atom Draft. This proposal seemed to have enjoyed some support, yet it did not seem to have made it into the current draft, despite being crucial to the solving the issue that PaceDuplicateIDs was designed to address. However, for it to work, the re-aggregator would need to have access to a self link, which is not required by the current draft. What should we do? One way to solve this is to require id *and* update Graham's original proposal accordingly, *and* incorporate it into the next (and presumably final draft). - - - That's what I meant by There is a danger of looking at changes in isolation.: http://www.imc.org/atom-syntax/mail-archive/msg15292.html Of course, breaking any link in my complicated chain of logic above would cause the whole argument to collapse, which would be fine with me. Does anybody see something that I am missing? - Sam Ruby
Re: Consensus call on last raft of issues
Sam Ruby wrote: 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. = I guess I wrote this too quickly last night, in any case, it wasn't clear to Paul, so it might not be clear to others. Off list, I offered the following, and Paul suggested that I post it to the list: There seemed to be consensus that feeds needed something to identify them. What there wasn't consensus on is which element should be that identifier. The solution selected was to make none of the identifiers required - something I don't think has much support, and furthermore creates problems with the ability to cite a source. Done! - Sam Ruby
Re: Consensus call on last raft of issues
Robert Sayre wrote: I broadly agree with the chairs' opinions. 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. Missed one: - There are many applications and users that *don't want* summaries. Some examples include Firefox, Cellphones, Tivos, and whoever is subscribing to JamesT's title-only feed. This makes the second bullet point false. It is not regrettable to provide applications with exactly what they need. However, I agree that some education is in order. 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. This statement seems overbroad to me, and doesn't directly speak to the data format. 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. Walter mentioned that he wouldn't index them, but just skip through them to the resources they're linking to. This is a title-only feed's purpose in life, so it's probably not a good example. I think it would be more productive to explain why one might want to omit a summary (see below). Feed producers should be aware of these issues and are encouraged to include a meaningful atom:summary in entries lacking atom:content wherever possible. See above. 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. We don't use the term 'software' in the draft. We discuss Atom Processors. If we were to define Atom Processors in opposition to an 'application', as in PaceDefineAtomProcessor, we could say a lot about applications. Note that one major goal of PaceDefineAtomProcessor is to avoid making normative requirements on applications. - Some applications may choose to require a minimum amount of inline text or (X)HTML data to function reliably and predictably. For that reason, atom:entry elements are advised to contain a non-empty atom:summary element when the entry contains no atom:content element. 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. 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. Sam Ruby wrote: 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, do you think any of your concerns could be incorporated into the text above? If so, please make suggestions. If not, could you be more specific about the parts of the Pace you feel were overlooked? A concrete example of my concern is that feeds with atom:entries containing atom:title/ will have those entries omitted by Firefox's livebookmark support. The proposed changes to sections 3.1.1.1, 3.1.1.2, and 3.1.1.3, apply to all text constructs, not simply atom:summary. All that needs to be done is to expand whatever wording we come up with to include title and content. - Sam Ruby
Re: Consensus call on last raft of issues
Robert Sayre wrote: How about this: Some applications may choose to require a minimum amount of inline text or (X)HTML data to function reliably and predictably. For that reason, atom:entry elements are advised to contain a non-empty atom:title element, a non-empty atom:summary element when the entry contains no atom:content element, and a non-empty atom:content element when that element is present. That works. Thanks! - Sam Ruby
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
Re: extensions -- Atom NS and unprefixed attributes
Tim Bray wrote: 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 A concrete example of the implications of such a rule: http://diveintomark.org/archives/2003/04/13/object_and_internet_explorer ... in particular, follow this link: http://www.robinlionheart.com/stds/html4/objects.html The only way that authors of future revisions of the specification can be confident that they are adding things that don't break anything is if either (1) some names (e.g., the atom namespace) are reserved for such things, or (2) all future additions go into new namespaces. I do believe that schemas and/or the feedvalidator can enforce such a rule. And I don't believe that a requirement that people who wish to extend Atom do so in their own namespace is overly burdensome. - Sam Ruby
Re: PaceAllowDuplicateIdsWithModified
Graham wrote: I'd like to propose an alternative to atom:modified? I've mentioned this a couple of times before over the last two years, but anyway: The only properties of atom:modified we're interested in are: 1) That different versions have different dates 2) Sorting chronologically puts the versions in the correct order This is to say, the absolute value of the date is irrelevant. The only thing that matters is whether it is before, after or the same as other dates that have appeared on a particular entry. Proposal: atom:version atom:version is a Date Construct that determines the chronology of instances of atom:entry. Each time an atom:entry is modified, atom:version MUST be given a chronologically later value than other values than have appeared in any atom:entry with the same value for atom:id. 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. Is this plausible? Potential concerns / observations: 1) cvs versions are numbered with things like 1.99 and 1.103. This makes such versions unsuitable for this purpose. How do we make this clear? 2) in the general case, sorting of unicode is culturally sensitive. This isn't a concern for RFC 3339 based dates given the constrained set of characters that that grammar permits. 3) Perhaps version/modified need not be mandatory except in those instances where entries with duplicate ids are present in a feed? 4) No semantics can be inferred by two different entries with two different ids sharing the same version. - Sam Ruby
Re: PaceOtherVocabularies
Robert Sayre wrote: Software written to conform to this version of the specification will not be able to process such markup correctly and, in fact, will not be able to distinguish it from markup error. Please replace that sentence with something reemphasizing the MustIgnore rule. Stating that nobody else is allowed to use the Atom namespace, coupled with a statement that everybody must ignore elements that they don't understand paves the way for future IETF spec authors to safely add optional elements in a backwards compatible manner. - Sam Ruby
Re: Fetch Me A Rock
David Nesting wrote: On Thu, May 12, 2005 at 03:46:21PM -0600, Antone Roundy wrote: The problem we have, as I pointed out earlier on the thread, is that we do not specify whether senders and receivers have the same SHOULD. I made one assumption, and Rob pointed out that I had made one different than he did. So because both RFC 2119 and the current Atom draft are not explicit on this point, it is open either to varied interpretations, or at least to misinterpretations. It is therefore up to us to clarify: A summary SHOULD* be present in an entry. Implementations MUST be capable of processing entries with and without summaries (title-only feeds). This is not intended to suggest that implementations must do something useful with title-only entries. * - The implications are that many processors will ignore or reject entries that do not have summaries, because the processor may place the emphasis of its processing on the summary. The feed as a whole is still valid, however, and it's expected that processors will handle entries that DO have summaries in the same feed as entries that do NOT. Very nice. - Sam Ruby
Re: On SHOULD
People seem confused about RFC 2119. If it helps, here is an example. But, be aware, it is JUST an example at this point. I'd like to be able to discuss it without people questioning each other's commercial viability, personal relevance to this process, or talking about things caching fire or the like, OK? I'm also staying away from atom:summary for the the moment as there continues to be more heat than light in that particular conversation. With that in mind, I suggest that the following are roughly equivalent: atom:title MAY be empty, but be aware that if it is empty, the recipient MAY chose to ignore the entire entry. atom:title SHOULD NOT be empty, lest the recipient choses to ignore the entire entry. While the latter is slightly stronger, what is being conveyed in each case is you are free to do this, but be aware that there are implications that you need to consider. This is not meant as a value judgment. And to illustrate this example, I offer the following for Firefox users: http://intertwingly.net/stories/2005/05/12/ Even with this example in mind, things are not cut and dry: We could decide as a group that titles MUST be present and not empty. Even knowing that this means that somewhere that somebody will create a feed either ignoring this requirement. And it might even work. But when things break, it is clear who to blame. We could decide as a group that titles SHOULD be present and not empty. This puts both parties on notice. If you include it, more things work. If you don't, many things will still work. Furthermore, people who parse feeds are put on notice that from time to time they will encounter entries with empty titles. We could decide as a group that titles are completely OPTIONAL. This is pretty much the reverse of the MUST case above. If things break, it is the recipient who is to blame. I claim that we are free to pick amongst all three of these alternatives. We would also shunt this issue off to a Best Current Practices document. What's worse, there is no magic numbers to guide us in this decision. Examples of things you WON'T find: if not including a title affects more than 17% of the user base or a if this affects a tool produced by a company with a market cap of greater than 6.3 billion dollars. It comes down to judgment. And on matters of judgment, reasonable people will disagree. - - - So far, we seem to have consensus that atom:id MUST be present in atom:entries. People who intend to consume atom feeds have expressed this requirement pretty clearly, and as a group we seem inclined to satisfy this requirement. So far, I don't recall anybody stepping forward and saying that feeds without atom:category elements will be less effective. Now that I have said that, I'm sure that somebody could come up with an example, but that would only prove my point that this is about judgment. - - - We have RFC 2119. We have Paul on record saying that if this actually is the will of the working group, scenarios such as these are appropriate uses of the word SHOULD. Note: this is not Paul advocating any particular outcome, simply saying that that option is open to us. With all this in mind, my suggestion is that we all calm down for a few days, and discussion things other than text elements. And when we do revisit this discussion early next week, lets not start with atom:summary, OK? - Sam Ruby
Re: PaceOptionalSummary
Robert Sayre wrote: On 5/9/05, Sam Ruby [EMAIL PROTECTED] wrote: I also feel the need to express deep dismay at the way that author of PaceOptionalSummary has been pursuing a scorched earth approach whereby everybody who expresses an opinion to the contrary is viciously attacked for doing so. I believe that this has significantly hampered the ability of the work group to hold a reasonable discourse on the subject. I believe the secretary significantly hampered discourse on this subject for *months*, by claiming the issue had consensus and was closed. It appears that the scorched earth campaign is destined to continue unabated. It is an interesting theory, now lets explore the facts. The secretary's job is to schedule the discussion of Paces. PaceOptionalSummary was authored on 2005/04/30, and scheduled on 2005/05/05. PaceOptionalSummary was preceded by PaceCoConstraintsAreBad, which was authored on 2005/04/06. It, too, was scheduled in the very next round of paces. I agree with Robert; it conflicts with PaceOptionalSummary and I doubt it would exist if PaceOptionalSummary had not make the cut. -1 as well. Doesn't solve a technical problem. It's just gamesmanship. Alternate theory. After months of foreshadowing, PaceOptionalSummary was exquisitely timed to coincide with last call. Along with a diversionary burst of fire concerning alleged process issues. Here's where SHOULD comes in. We're lucky that we have an example of what happens when a SHOULD is violated. I'm sure most of you saw the nasty arguments, accusations, and all-around busted software that happen this week with Google Web Accelerator and Ruby On Rails.[0] Ugly, right? This WG should be proud that we've kept the SHOULDs to a minimum. Interesting analogy, let's see how it pans out. The W3C could have made idempotency a MUST, which effectively would have prevented useful things like hit counters. Or they could have made idempotency a MAY, slamming the door shut not only things like Google's WebAccelerator, but also on all web crawlers. Instead, they decided to make idempotency a SHOULD, opening the door for web crawlers by putting servers on notice that in the event of a conflict, the onus is on them. - - - Back to Atom. If a entry in a feed does not include a title, and Firefox's Live Bookmark support choses not to display it, who is the onus on? If an entry in a feed contains neither a textual content nor a summary, and Walter's search engine choses not to index it, who is the onus on? Simply put, PaceOptionalSummary is incomplete. Also, I'm having trouble reconciling your road lying with the assertion that the two proposals are compatible. How can they be if their outcomes are so different? In my note yesterday morning, I made it abundantly clear what I objected to. It wasn't the text between the ==Proposal== and ==Impacts== markers. - - - The W3C got it right. And so should we. Answer the two questions above. Without hysterics like burst into fire. What we actually are talking about here is aggregators that drop information on the floor. Should we warn producers about this? - Sam Ruby
Re: Atom 1.0?
Walter Underwood wrote: I'd also be happy with just Atom and saying RFC Atom when pressed for a version. +1 - Sam Ruby
Re: PaceOptionalSummary
Antone Roundy wrote: +1. ...oh, and the wording I just suggested for part of PaceTextShouldBeProvided would depend on this also being accepted. With deep regret, I'm going to express my -1 on PaceOptionalSummary. Not because I object to the text expressed in the proposal section. In fact, I clearly do not as I lifted large sections of it to be placed into PaceTextShouldBeProvided. No, it is because the author of PaceOptionalSummary has made it clear that he interprets the two paces to be incompatible, so each and every +1 for PaceOptionalSummary is a vote against PaceTextShouldNotBeProvided. Despite wording that accompanied several of these +1's, like the wording describe above. I also feel the need to express deep dismay at the way that author of PaceOptionalSummary has been pursuing a scorched earth approach whereby everybody who expresses an opinion to the contrary is viciously attacked for doing so. I believe that this has significantly hampered the ability of the work group to hold a reasonable discourse on the subject. Despite this, I have attempted to see if there was some common ground to be found. I drafted up a Pace, and offered a few suggestions. It has since become clear to me that PaceOptionalSummary is being pursued in a winner take all manner. As such, I see no other path than to offer my -1 on the Pace. Face down, arms and legs outstretched, in the middle of the road. One thing I would like those who advocate PaceOptionalSummary to the exclusion of all other Paces on the subject to consider... what happens if the chairs determine that consensus can't be found on either of these paces? Look at the current wording of draft-08. Is that what you really want? We can do better. - Sam Ruby
Re: PaceOptionalFeedLink
Graham wrote: On 6 May 2005, at 3:50 am, Sam Ruby wrote: FYI: we have an instance proof of this requiring an existing tool to do additional work: http://www.imc.org/atom-syntax/mail-archive/msg13983.html Tools will have to be updated to work with Atom? Scandalous. +1 to the Pace This Pace is not one that I plan to lie down in the road over. However, it continues to puzzle the bejeebers out of me. The channel link element is required in every version of RSS from 0.91 to 1.0 to 2.0. And as a co-author of the feedvalidator, I have seen a lot of broken feeds where people have either inadvertently or deliberately ignored the specification, but I don't recall ever seeing one where this element was not present. My concern is not that tools will need to be updated. My concern is that tools won't know that they need to update. How will they know that they need to update to handle a set of feeds that nobody is currently providing? Something that WOULD attract my attention is somebody saying here is a set of feeds that I would like to provide that I can't provide in a valid way according to any of the available RSS specifications. - Sam Ruby
Re: PaceTextShouldBeProvided vs PaceOptionalSummary
Bill de hÓra wrote: 3. It's the kind of spec text we have rejected in the past as impletation specific and/or best current practice guidance: those that follow these suggestions will find that their feeds are useful to a wider audience than they would be otherwise. Um, that text is not part of the proposal. It is part of the rationale. - Sam Ruby
Re: FeedId
Bill de hÓra wrote: PaceFeedIdOrAlternate, withdrawn, no comment PaceFeedIdOrSelf 0 PaceOptionalFeedLink +1 I agree with the rationale; no point making people things they can't do. I'm assuming that if PaceOptionalFeedLink goes through feed:id is a MUST. On what do you base that assumption? - Sam Ruby
Re: FeedId
Graham wrote: On 6 May 2005, at 4:28 pm, Bill de hÓra wrote: That there is consensus we'll want to identify a feed, even if we can't provide a link. I'd +1 an ordinary make feed:id required Pace. I'd +1 any Pace that has a chance of achieving consensus that makes at least one element that can be used as a feed identifier mandatory. At the moment, alternate link is the element of record. -1 to PaceOptionalFeedLink if it to be accepted in isolation or to be portrayed as inconsistent with any other feed id related paces (hey, I might be dumb, but I learn quick) +1 to any Pace that moves this to responsibility to a more appropriate home. - Sam Ruby
Re: Selfish Feeds...
Bob Wyman wrote: I've got another example of a selfish feed which is producing dynamic content which will cause many duplicate entries to float around the blogosphere. The feed in question here is an RSS feed. Nonetheless, I think we must expect people will do the same stupid tricks with Atom feeds. Check out: http://www.b-eye-network.com/xml/articles.php What you'll get is a feed with entries that look something like the one at the bottom of this page. The interesting thing to note is that the item has a link element with the url: linkhttp://www.b-eye-network.com/view/index.php? cid=836fc=0frss=1ua=Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; Alexa Toolbar)/link What's happened here is that the site has appended my User Agent to the URL in the link. I assume that this is to allow some kind of tracking. However, the impact is that the contents of the feed depend on what tool you use to read the feed. If you access the feed, you will undoubtedly get different content then I did... For instance, if PubSub's crawler had read the feed, the value of the ua attribute in the URL would have been different and the URL would have read: linkhttp://www.b-eye-network.com/view/index.php? cid=836amp;fc=0amp;frss=1amp;ua=PubSub.com RSS reader - http://www.pubsub.com//link If this feed is read by more than one synthetic feed generator or if items from the feed are copied from this feed to another, it is inevitable that we'll have multiple copies of the item floating around and we'll have very little means for determining which one is authoritative -- essentially they all are. It would be handy to have a dynamic content flag that allows us to ignore this stuff... It seems to me that instead of adding a dynamic content flag, having a separate id element (or in RSS 2.0's case, utilizing the guid element) would be more to the point. - Sam Ruby
Re: PaceOriginalAttribute
Tim Bray wrote: +1 I'm not 100% convinced it solves the problems Rob says it does, but it seems cheap, lightweight, and unlikely to cause any harm. -Tim I'm growing increasingly comfortable with the concept of allowing redistributors to assign new ids as long as they track the original (i.e.: not immediate predecessor!) entry. That being said, I have two things I want to think more about w.r.t. how this Pace is currently worded. (Note: the first is actually only a nit concerning the current draft, not the Pace itself): 1) MAY be preserved I would prefer if this were recast not so much as an RFC 2119 interoperability statement, but rather as a definitional one. original attributes in atom:source elements are used to indicate... Something along those lines. 2) Atom feeds MUST NOT contain duplicate atom:id values How did that get in there? Depending on how you read it, this Pace is incompatible with PaceAllowDuplicateIDs, implying that Tim's +1 above can be construed as voting against a Pace he authored! Whether or not the work group comes to consensus about allowing multiple entries to share the same ID in a feed, it still is true that entries may change over time. Perhaps atom:source elements could also define an @updated attribute. As atom:updated is a required element for atom:entry, it would not be an unreasonable burden to require @updated attributes on atom:source elements. - Sam Ruby
AtomPubIssuesList for 2005/05/05
*** REMINDER ** ** Use more specific subject lines when responding to this note! ** *** REMINDER ** First the meat... here's the new atom pub issues list, conveniently sorted into categories: EntryId: http://intertwingly.net/wiki/pie/PaceAllowDuplicateIDs http://intertwingly.net/wiki/pie/PaceDuplicateIDWithSource2 http://intertwingly.net/wiki/pie/PaceDuplicateIDWithSource http://intertwingly.net/wiki/pie/PaceExplainDuplicateIds FeedId: http://intertwingly.net/wiki/pie/PaceFeedIdOrAlternate http://intertwingly.net/wiki/pie/PaceFeedIdOrSelf http://intertwingly.net/wiki/pie/PaceOptionalFeedLink Provenance: http://intertwingly.net/wiki/pie/PaceOriginalAttribute http://intertwingly.net/wiki/pie/PaceSourceRecs Status: http://intertwingly.net/wiki/pie/PaceEntryState http://intertwingly.net/wiki/pie/PacePubControl http://intertwingly.net/wiki/pie/PacePubStatusResource Text: http://intertwingly.net/wiki/pie/PaceBriefExample http://intertwingly.net/wiki/pie/PaceCoConstraintsAreBad http://intertwingly.net/wiki/pie/PaceOptionalSummary http://intertwingly.net/wiki/pie/PaceRecommendPlainTextContent http://intertwingly.net/wiki/pie/PaceTextShouldBeProvided Recommended for Closure: http://intertwingly.net/wiki/pie/PaceXhtmlDivSuggestedOnly http://intertwingly.net/wiki/pie/PaceXmlContentWrapper Now for some administrivia. No progress was made on the last published issued list[1], so I've gone ahead and marked those issues that were recommended for closure, closed; and those currently under discussion were moved back to Needing to Revisit. Next, I'd like to remind everybody that last call for the Atom Format went out. Operationally, what this means is that the secretary and co-chairs are going to be increasingly reluctant to revisit things simply because somebody wants to bring them up again. What that means is that in order to successfully bring up an issue, you need to do a little homework. Demonstrate that you have revisited the previous discussion, and that you either have something new to add, or can point out some evidence that the previous consensus call was made in error. Tim has taken the opportunity to lead by example on this one with PaceAllowDuplicateIDs. The secretary and co-chairs all are in agreement that the XhtmlDiv related paces don't meet this criteria. If anyone disagrees, what we would like to ask is that you follow Tim's lead. Because we are in last call, I've scheduled everything related to the Format document. As one of the status paces touches on the format, I've scheduled all three. All we need to resolve now is the extent to which this is going to affect the format document. I believe that PaceBriefExample is truly editorial, meaning that the editors can act on this at their discretion. - Sam Ruby [1] http://www.imc.org/atom-syntax/mail-archive/msg13691.html
Re: AtomPubIssuesList for 2005/05/05
Walter Underwood wrote: --On May 5, 2005 7:17:00 AM -0400 Sam Ruby [EMAIL PROTECTED] wrote: Demonstrate that you have revisited the previous discussion, and that you either have something new to add, or can point out some evidence that the previous consensus call was made in error. PaceCaching was not discussed and rejected based on false information. It was rejected because it was HTTP-specific (it is not), and because it was non-core (similar features are common in other RSS specs). Actually, it never has been rejected. I had miscategorized it as protocol. I've fixing that now, and scheduled it for this cycle. Sorry for the confusion. - Sam Ruby
Re: PaceTextShouldBeProvided
Robert Sayre wrote: On 5/5/05, Antone Roundy [EMAIL PROTECTED] wrote: +1 except for one thing: In section 4.1.2, I'd suggest something along these lines: atom:entry elements which do not contain an atom:content element, or whose atom:content element's type attribute indicates a MIME media type, SHOULD contain an atom:summary element. This Pace is incompatible with PaceOptionalSummary and incomplete. -1. Something a little less curt would be appreciated. The stated abstract of PaceOptionalSummary (i.e., removing the requirement for atom:summary) is met. In your mind, this equates to completely optional. That has yet to be conclusively established. What concerns me more, however, is that interoperability issues that PaceOptionalSummary not only creates, but also uncovered during its discussion. Unless there is some plan for addressing these interoperability issues (and by that, I mean something more constructive than That's fine, but we're not here to tailor the format to your app.), then perhaps BOTH paces are incomplete. There are a number of ways to finesse the identification of the issue into the spec. For example, take a look at how Tim worded PaceAllowDuplicateIDs. Producers are put on effectively put on notice that if they include multiple entries with the same ID, that some or all of them may be ignored. How should we convey a similar sentiment about the reality that entries without a readily available textual representation may suffer the same fate? - Sam Ruby
Re: PaceOptionalFeedLink
Tim Bray wrote: +1 There are people who want to publish feeds without rel=alternate links. I'm against telling people they can't do something they want to do without strong reasons, as in loss of interoperability. I don't see the reasons here as strong enough. -Tim FYI: we have an instance proof of this requiring an existing tool to do additional work: http://www.imc.org/atom-syntax/mail-archive/msg13983.html - Sam Ruby
Re: PaceFeedIdOrSelf
+1 From prior discussion, people have indicated that they want *something* that they can use to track feeds identity, and the consensus seemed to be that id and/or self was more appropriate than link. - Sam Ruby
Re: PaceExplainDuplicateIds
John Panzer wrote: Eric Scheid wrote: On 2/5/05 1:51 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: I would +1 allowing identical IDs if it was required that the entries sharing an ID had different sources. perhaps we need to explain the concept of 'entries' (as resources), as distinct from entrys (as representations), and explain that 'entries' must have unique IDs, and that the atom:id element of any atom:entry ties it back to the 'entry' resource. It would then follow that multiple entry representations which happen to have the same atom:id value are just different representations of the source 'entry', and possibly even different instantiations in time. e. +1. To me, this sounds very much like the following Pace: http://www.intertwingly.net/wiki/pie/PaceRepeatIdInDocument If the current proposal is different, how so? If not, have people reviewed the discussion that occurred when that particular proposal was brought before the working group? - Sam Ruby
Re: PaceTextShouldBeProvided
Robert Sayre wrote: On 4/29/05, Sam Ruby [EMAIL PROTECTED] wrote: == Abstract == Encourage interoperability and accessibility by suggesting that key textual constructs be both present and non-empty. I'd prefer that a bit more of the rationale made it into the text. Explain why we are saying SHOULD. Suggestions? Is this something that the editor can handle? === section 4.1.2 === Add: atom:entry elements SHOULD contain an atom:summary element if the atom:content in the form of atomInlineOtherContent. This section needs to be reworked. We can't make normative reference to the RNG. Suggestions? Is this something that the editor can handle? == Notes == In the event that PaceOptionalSummary is adopted, the words is either not present or would need to be added to the proposed addition to section 4.1.2. -1 to this. If PaceOptionalSummary is adopted, the summary will be a MAY, not a SHOULD. Please put your proposals in the section marked Proposal. At the moment, the proposal is based on the existing draft-ietf-atompub-format-08. PaceOptionalSummary does not introduce a MAY, it removes a crucial MUST -- one that, if removed, would exasperate the problem that PaceTextShouldBeProvided is intended to address. - Sam Ruby
Re: PaceExplainDuplicateIds
Robert Sayre wrote: On 4/30/05, Antone Roundy [EMAIL PROTECTED] wrote: On Saturday, April 30, 2005, at 02:02 PM, Robert Sayre wrote: The proposed compromise to allow duplicate IDs in feeds, on the condition that a source element is present, doesn't address the problem of quick scripts that probably won't group duplicate IDs. I don't understand the last part of this sentence--could you explain? Sure. Take a look at the discussion here: http://www.intertwingly.net/blog/2005/04/09/Clone-Wars Say someone writes a quick PHP script that doesn't keep any state and loops through the entries to display them on a web page. They'll have different results than a well-written desktop aggregator. There can be no expectation about interoperability of invalid feeds. In the feed mentioned there, I presume that the spid part of the URI was meant to be substituted with some sort of product id. The ids encoded inside the links clearly would do. Heck, the links themselves are better globally unique identifiers than the ones provided as the guids. One of the clearest requirements that aggregator authors have provided to Atom is the wisdom of requiring unique IDs on entries. There may be consensus that unique by source is sufficient. - Sam Ruby
Re: PaceOptionalSummary
Robert Sayre wrote: On 4/28/05, Roger B. [EMAIL PROTECTED] wrote: Do you have an example? Robert: I'm an example. I also drop title-free feeds (see Scripting News)... given the nature of the app, a feed without titles or content is just worthless. That's fine, but we're not here to tailor the format to your app. Robert: why did you ask for an example? - Sam Ruby
Re: Cleanup phase
Graham wrote: On 28 Apr 2005, at 11:34 am, Bill de hÓra wrote: I haven't seen any objections to title only feeds which you state is my and Sam's and other's position (we object to feeds that could have a summary included but don't). That last objection in parens sounds like some of the positions held around dates - that providers ought to do the right thing for some definition of the right thing. Given that legacy, I'll claim it's clear we're not here to police what people ought do with feeds that could have a summary. Then what are we here to do? Would you support removing all of the other requirements from the spec? And if Robert's assertion elsewhere (Every bit of syndication code written since my.netscape.com in 1999 can deal with title-only feed) is remotely true , ie there's not large number of codebases that will break, then you can add innovation through standards to my list of objections to any position that makes summaries non-optional. First, note that this is mistating Graham's position. He is not arguing that summaries be made non-optional. Every code base can also cope without dates or ids. We still require them. This is not a theoretical discussion. Quoting from RSS 0.92[1]: * All sub-elements of item are optional * any 0.92 source is also a valid 2.0 source Is this really where we want to go? - Sam Ruby [1] http://backend.userland.com/rss092
Re: PubSub CAN NOT support Atom with existing no duplicate id constraint
Bob Wyman wrote: I know that nobody seems to like this issue However, I have explained on numerous occasions that the existing prohibition against duplicate ids in a feed simply cannot be supported by PubSub or any other feed aggregator. The problem is, once again, that prohibiting duplicate ids provides an easy to use attack vector for those wishing to effectively erase entries written by another author. (i.e. by publishing an entry with an id identical to one published earlier, one can force the earlier entry to be flushed from Atom feeds.) If synthetic feed generators such as PubSub implement the current prohibition against duplicate ids, they will simply become open channels for attack. Well soon see anti-abortionists publishing entries with ids identical to those of entries whose content they disapprove of. Well see ex-boyfriends attack critical entries written by girls whom they displeased on Saturday night. Well see skinheads flush from the system any entries that might have been written by jews and blacks. This is not good and I will not allow the system I build to be used in this manner. Graham Park has proposed that we loosen the existing language to permit duplicate ids in the case where the entries have atom:source elements which identify different URIs in self links. I support this compromise and believe it should be supported by the WG and incorporated into the Atom Draft. I dont believe the issue here is one of taste and I dont see any responsible option other then modifying the existing constraint. No one has been able to provide any argument which explains why the attack vector I describe is **NOT** a problem. If the WG refuses to modify this constraint, then it should at least feel compelled to include text in the security considerations section that clearly describes the attack and lets people know that no atom entry is safe from trivial attacks as a result of this constraint. If the WG refuses to modify this constraint, then they should expect that responsible feed aggregators and generators of synthetic feeds will simply be forced to deny support for Atom as specified. If anyone has a clear argument explaining why the attack is not possible or not a problem, they should make it. Alternatively, if you have a better method then that proposed by Graham for defending against the attack, please describe it. Otherwise, Grahams compromise should be accepted and the specification revised. It would help if a Pace could be written. IIRC, the objections to PaceRepeatIdInDocument centered around the request to support multiple versions of a resource - a concern that does not apply to Graham's proposed compromise. - Sam Ruby
Re: PaceOptionalSummary
Tim Bray wrote: I was driving to the airport with Lauren, whom some of you will know, she's technical but hasn't been following Atom. I explained the debate we are having over the required-ness of atom:summary, and she said Don't you have anything better to talk about? I suspect she has a point. Suppose we leave it the way it is... people who don't want to include a summary can use summary/, so it's just silly to say that there's an example of a current feed that would be ruled out. For that matter, Graham's body-only feeds can be done with title/. I can see Sam's arguments, but on the other hand, the errors that might get caught by requiring summary are probably boring corner-cases anyhow. Which is to say, it doesn't matter very much. Which is to say, Paul I are gonna watch a little more debate and then we'll call rough consensus one way or the other, at which point I at least will become crushingly rude to anyone who wants to invest more time in this. -Tim The feedvalidator catches silly, boring corner-cases every day. I hesitate to bring it up again as it has proven to incite adhominen attacks from within this workgroup, but we have an example of a respected journalist who has published a book in which he specifically called out this. And we have the experience from RSS 2.0 (motto: everything is optional! and extensible!) whereby Don Box introduced xhtml:body into his feed in place of description, something that most aggregators support today. On the other hand, what we have is arguments that entries with empty summaries is not possible with the current format - something that is blatantly incorrect. We also had a very complex and delicate negotiation a while back that seems to have been forgotten. It is quite possible to produce feeds with content that is base64 encoded binary or out of band. What is desired in such circumstances is precisely akin to specifications that require alt attributes for img tags. It atom's case, it is a summary. If you want to push through this pace, I suggest that we revisit and reopen those discussions. Schedule be damned. - Sam Ruby
Re: PaceOptionalSummary
Graham wrote: This argument has a got a bit sidetracked. My position is: a) I think title-only feeds should be allowed where there's nothing sensible to put in the summary or content elements. b) Under all other circumstances, a summary of some kind should be required when atom-based textual content is absent. The pace as written newly allows the omission of a summary and content on the whim of the publisher. It also allows its omission when the content of the entry has been placed in a non-atom container. My first problem is that neither of these consequences seem intended. My second is that it is the interopability issue. I'm within my rights as a consumer to reject title-only feeds as not worth bothering with (before you condemn this as an arbitrary decision, bear in mind the current Atom spec makes the same judgement). The atom spec would not give publishers fair warning of this. This is why I think it makes more sense as a SHOULD requirement. Well stated. I'd also add that apparently summary SHOULD be non empty in all of the cases where it is currently required as well as one new case: the case where the content is empty. - Sam Ruby
Re: PaceOptionalSummary
Robert Sayre wrote: On 4/26/05, Sam Ruby [EMAIL PROTECTED] wrote: Graham wrote: The pace as written newly allows the omission of a summary and content on the whim of the publisher. That's right. I'm within my rights as a consumer to reject title-only feeds as not worth bothering with (before you condemn this as an arbitrary decision, bear in mind the current Atom spec makes the same judgement). It is arbitrary. My point is that the spec does not reflect consensus in this working group or help interop. You're within your rights to reject anything, you just want the spec to back you up, and that's ridiculous. The atom spec would not give publishers fair warning of this. This is why I think it makes more sense as a SHOULD requirement. Well stated. I'd also add that apparently summary SHOULD be non empty in all of the cases where it is currently required as well as one new case: the case where the content is empty. Nonsense. Never. There are plenty of people here disagreeing with you. If you attempt to syndicate a contentless and summaryless entry, there will be people who drop it on the floor. It doesn't matter how many people write software that behaves otherwise, it is a reality that some will behave this way. From RFC 2119: SHOULD This word, or the adjective RECOMMENDED, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. I am willing to concede that there are valid reasons in particular circumstances to ignore the requirement for a summary. Are you willing to concede that there are implications to such a decision that must be understood and carefully weighed before chosing to omit a summary? - Sam Ruby
Re: PaceOptionalSummary
Tim Bray wrote: On Apr 25, 2005, at 11:01 AM, Graham wrote: Can you post some links to examples of feeds you think are difficult to express in the current syntax? That would be considerably more constructive than whatever the hell that was. What Rob wants is what he said in http://www.imc.org/atom-syntax/mail-archive/msg14157.html I decided it would help if there was an actual Pace: http://www.intertwingly.net/wiki/pie/PaceOptionalSummary -1 Steamroll over me and others if you must, but I believe that title only feeds are more often that way due to an error of omission than by an explicit design choice. Enough so that it warrants someone explicitly saying this summarly intentionally left blank, thus: summary/ Given a way to express an intentional omission of a summary, this discussion changes from a discussion of use cases that allegedly are not supported, to one of whether tools like RNG grammars and feedvalidators can assist people who produce feeds in making their intents clear. - Sam Ruby
Re: Last Call: required summary or content?
Robert Sayre wrote: * What the specification does currently In an Atom Entry, the specification currently requires a minimum set of elements: title, id, and updated. Typically, there will also be a link element. The specification includes a provision that allows its omission on the condition that there is a content element. In addition to that, the specification requires that either summary or content be present. * What you would like it to do instead I want to allow the metadata-only feeds allowed by all flavors of RSS, and the omission of the content and summary. Such feeds are commonly termed title-only feeds, because that is all that is visible to the user (the title is usually hyperlinked w/ the link element). I will again point out that the current format allows for empty summary and/or content elements. I have seen errors that the requirement for the inclusion of such elements would have prevented. I have seen no arguments as to why placing such empty elements would impose an unreasonable burden on implementers. - Sam Ruby
Re: PaceCoConstraintsAreBad
Robert Sayre wrote: Sam Ruby wrote: If, instead, it opens the door for multiple changes without explicit rationale; at the last minute; overturning carefully formed consensus; then it was not. Uh, so your changes are ok, but mine aren't? We continue the lovely pattern of DOSing proposals. Unfair. I've withdrawn my proposal. At this point, small surgical changes to address specific concerns may (or may not) be acceptable. Wholesale changes with little rationale are less likely to be so. - Sam Ruby
Re: PaceCoConstraintsAreBad
Robert Sayre wrote: Sam Ruby wrote: Content remains optional. The pace did not drop the requirement for a link element in the absence of content. OK, I missed that. What else did I miss at this late date? As it stands, this Pace declares co-constraints bad, selectively removes a few co-constraints, and leaves others, with little rhyme or reason. Am I misreading the Pace? The abstract seems clear enough... While I agree with your recent statement that no one has spoken up in favor of the current text, I resonate more with Paul's recent statement[1] that: It doesn't matter whether or not they are too controversial; the spec is frozen for significant technical changes. Unless, of course, the WG decides we really do want to open it all up again an take another probably four months of deciding what else we want to add and change. We can do that by amending our charter. So far, I have not heard consensus going towards that, but I could be wrong. I wrote a Pace that inserted seven words and only changed one element, feeling that we might be able to come to an agreement on that. This appears to have been a tactical error... Strawmen are usually tactical errors. It was a serious proposal. And if it results in a clear consensus around PaceFeedIdOrSelf, then it was useful. If, instead, it opens the door for multiple changes without explicit rationale; at the last minute; overturning carefully formed consensus; then it was not. My order of preference: PaceFeedIdOrAlternate PaceFeedIdOrSelf Current Text PaceCoConstraintsAreBad no one has spoken up in favor of the current text remains true. I am willing to go with PaceFeedIdOrSelf. A number of people have expressed support for it. I don't know if it meets a threshold or not - at the moment the bar is pretty high. And the number of active proposals is troublesome. I've marked PaceIdOrAlternate withdrawn. I remain -1 on PaceCoConstraintsAreBad. Robert Sayre - Sam Ruby
Re: PaceCoConstraintsAreBad
Robert Sayre wrote: Sam Ruby wrote: At this point, small surgical changes to address specific concerns may (or may not) be acceptable. Wholesale changes with little rationale are less likely to be so. Well, who really cares anyway. I'll get the draft ready. Nobody propose any 'wholesale changes' in the meantime, OK? I don't know about you, but I do care. Whether it is for accessibility, or for general usability, I want to ensure that every entry has a textual, non-remote component to it. You have made a number of noises that it is your intent to use last call as your opportunity to challenge the working group to revisit this. Please don't. If you truly are concerned about co-occurrence constraints, recast the grammar so that content and summary are the same element, possibly with multipart alternatives. See if you can come up with a less hideous syntax than either 0.3 or -07. Make this element mandatory, and I'm happy. If your real goal, however, is to make textual non-remote information optional, please don't. - Sam Ruby
Re: PaceCoConstraintsAreBad
Robert Sayre wrote: http://www.intertwingly.net/wiki/pie/PaceCoConstraintsAreBad Abstract Require atom:id, atom:title, atom:updated, atom:author. That's it. Status Open Rationale The spec delivers value when it can make an element mandatory. co-constraints are bad. Entries without either a summary or content or even a link to where you can find the data are worse. -1 - Sam Ruby P.S. If it pleases your sense of aesthetics, merge these three elements into one mandatory element, with an attribute to specify whether the innerxml represents a summary or a content, and another optional element specifying the location. Oh, and allow multiples of this element as there are scenarios in which both summaries and content are provided.
Re: PaceCoConstraintsAreBad
Robert Sayre wrote: Sam Ruby wrote: co-constraints are bad. Entries without either a summary or content or even a link to where you can find the data are worse. Does my Pace allow such a creature? This pace dropped the requirement for an alternate link. This pace dropped the requirement for a summary when content is not present. Content remains optional. Am I misreading the Pace? The abstract seems clear enough... While I agree with your recent statement that no one has spoken up in favor of the current text, I resonate more with Paul's recent statement[1] that: It doesn't matter whether or not they are too controversial; the spec is frozen for significant technical changes. Unless, of course, the WG decides we really do want to open it all up again an take another probably four months of deciding what else we want to add and change. We can do that by amending our charter. So far, I have not heard consensus going towards that, but I could be wrong. I wrote a Pace that inserted seven words and only changed one element, feeling that we might be able to come to an agreement on that. This appears to have been a tactical error as it was immediately followed by a pace that changed one word and added twenty one, affecting two elements. Now you introduce a pace that changes the definition of three elements. My order of preference: PaceFeedIdOrAlternate PaceFeedIdOrSelf Current Text PaceCoConstraintsAreBad - Sam Ruby http://www.imc.org/atom-syntax/mail-archive/msg14049.html
Re: Obs on format-07
An additional observation: neither of the examples in section 1.1 include the summary element. Suggestion: change the content in the first (minimal) example to summary. - Sam Ruby
PaceFeedIdOrAlternate
http://www.intertwingly.net/wiki/pie/PaceFeedIdOrAlternate Background: there seems to be some feeling that *something* should be required. Opinions vary from id should be a MUST to id is at best a MAY. While there are use cases for feeds without alternate html representations, I've been concerned that they are such outliers that the would be mostly ignored by the predominant feed producers; with the inevitable result that such feeds would be poorly handled and would therefore reflect poorly on both the authors of such feeds and the feed format itself. As this issue keeps coming up, this concern is lessening for me. Notes: this pace was written in such a way to minimize the amount of change to the existing document. It does not express a preference between the two elements. Upgrading one or both elements to a SHOULD would require a separate Pace. Upgrading the Self link to a SHOULD or MUST would require a separate Pace. - Sam Ruby
Re: [FeedValidator] atom 0.3 feed with link rel=related considered valid by feedvalidator
patrick chanezon wrote: I wanted to get your opinion about this, and maybe some rationale about why you chose this approach in FeedValidator, which is supposed to adhere more strictly to the specs than our parsing library. First, a statement of direction. At or shortly after Atom 1.0 goes final, the feedvalidator will no longer consider Atom 0.3 feeds as valid. As to pre-IETF history, the development was quite a bit less formal and rigorous, and therefore a number of factors were considered in the Atom 0.3 support. In particular, the following two sources were also taken as input: http://intertwingly.net/wiki/pie/LinkTagMeaning http://www.xml.com/lpt/a/2004/06/16/dive.html - Sam Ruby
Re: AtomPubIssuesList for 2005/02/22
Ezra Cooper wrote: I don't object to these being closed, but I'd like to have the chance to make a new proposal which would be an alternative to PaceEntryQuery. My proposal will: * provide for collections, obeying the slash semantics * allow for date-range queries over any (top-level) collection or sub-collection * not provide for index-based ranges, or other kinds of searches. If I can have this done by the end of the day, could we discuss it in this round? Yes. - Sam Ruby
Re: link rel=link type=????/
Bob Wyman wrote: However, atom requires that a link element have a mime-type. Given that we have no idea what the mime-type for the URI is, what mime-type should we use? It type attributes are optional in the current draft. http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-05.txt 4.6.3 The type Attribute Link elements MAY have a type attribute, whose value MUST conform to the syntax of a MIME media type [RFC2045]. This was changed in Format-03 as a result of the following: http://www.intertwingly.net/wiki/pie/PaceLinkAttrDefaults (Note: there is a typo in abstract, should be make the TYPE attribute optional) - Sam Ruby
Re: PaceRepeatIdInDocument solution
Bob Wyman wrote: Given that history shows that publishing repeated ids has never bothered anyone enough to cause them to complain, we should permit this benign practice to continue. I have exactly the opposite experience. I have people who have thanked me for noticing that they have repeated ids as it indicated an error in their software. - Sam Ruby
Re: TEXT, HTML, and XHTML
Tim Bray wrote: On Feb 17, 2005, at 10:25 AM, Joe Gregorio wrote: On Thu, 17 Feb 2005 12:12:49 -0500, Norman Walsh [EMAIL PROTECTED] wrote: Any chance we could change those attribute values to text, html, and xhtml? I originally wrote them that way to make it painfully obvious to the eye that THIS IS NOT A MEDIA-TYPE, but I'm not religious about it. -Tim I PERSONALLY DON'T THINK THAT SHOUTING IS NECESSARY. - Sam Ruby P.S. ;-)
