Fwd: Atom format interpretation question
Begin forwarded message: From: John Cowan [EMAIL PROTECTED] Date: January 4, 2007 8:08:06 AM PST (CA) To: [EMAIL PROTECTED] Subject: Atom format interpretation question Am I right in thinking that content which is in fact in XML but is labeled with a media type that is neither generic XML nor ends in +xml cannot be included inline in an Atom entry? The NewsML community (which uses the registered media-type text/vnd.IPTC.NewsML) is concerned about this. -- John Cowan [EMAIL PROTECTED] http://ccil.org/~cowan Any sufficiently-complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp. --Greenspun's Tenth Rule of Programming (rules 1-9 are unknown)
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On Dec 15, 2006, at 5:00 PM, Lisa Dusseault wrote: I guess I'm assuming that one would want clients to be able to extend Atom unilaterally. That doesn't seem to have been a design goal for the WG. To the extent that the issue never came up in the discussion. The choices that I highlighted as problematic make it harder for clients to reliably add extensions to Atom documents. You're being tactful with harder. I'd say impossible. Here's my take on the WG thinking: The set of software implementations which could reasonably act as APP servers is incredibly large and heterogeneous. A lot of them already exist. The requirement that they reliably round-trip arbitrary XML from clients is actually pretty onerous, since many (all?) of them will have internal data-storage models which will look very little like the Atom XML representation. We think that APP as specified allows very good interoperability for basic Web-centric publish/edit operations with low overhead, and low demands for complexity in the client and sever implementations. Adding the requirement for client-side extensibility would reduce the number of server implementations that would be able to advertise conformance with APP, even though they are perfectly capable of the highly-useful function possible under APP as of the current draft. (It remains easy for servers to add extensions to Atom feeds and entries using prescribed mechanisms like adding new elements in custom namespaces. ) Right. Phrased another way, the APP is highly extensible; but the current version requires co-operation from both client and server. This seems reasonable to me. It may be that I'm just having trouble accepting that the WG fully understands this and has still come to consensus that this is a great way to proceed. Is that the case? Sort of. Frankly, there seems to have been very little hunger for unilateral client-side extension, and a very strong aversion from the server-side people to accepting the round-trip-any-XML requirement. -Tim
Re: AD Evaluation of draft-ietf-atompub-protocol-11
Lisa Dusseault wrote: Can a client modify an entry to contain a link relation element in the following cases: - To point to a resource on a different server entirely? There is no reason to believe that any of these resource are on the same machine to begin with. I could POST to media to machine A and have the MLE could be created on machine B and the editable media resource itself created on machine C. This requirement has to be stated explicitly, at least as a SHOULD. Hmm. One particular operation in the APP is defined as creating two resources; we specify how this is requested and the mechanism by which the server communicates the URIs that identify the newly-created resources. It would feel really weird to me to specify anything about what servers the resources might be on. That's not how URIs work or how the Web works. You can't tell by looking at a URI what server the resource is on, anyhow. The URI might not be an HTTP URI. Two URIs that look very much the same might reference data on different continents. That's the whole point of how URIs work. Having said that, Lisa has already pointed out shortcomings in the number and placement of examples concerning this particular case. I think it'd be a good idea to have the example showing the Media resource showing up at http://media.example.com and the MLE showing up at http://app.example.com. But I'd be very much against side-tripping the protocol definition into any discussion of servers. 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. Well, except there are several examples of APP clients that seem to do just fine. Example: After extensive discussion, the WG achieved consensus that APP servers are *not* required to retain foreign markup. Example: It is perfectly possible to imagine a server that morphs or prunes incoming entries for reasons of political censorship, security policies, markup standards, spelling-correction, automatic translation, or lots of other things we can't possibly imagine. Example: my Ape protocol exerciser posts entries with a separate content and summary fields. At least one of the servers I've tested against accepts posts but discards my summary and generates its own, algorithmically. The range of things a server can usefully choose to do currently exceeds our ability to specify or constrain. Fortunately, in HTTP, we have a protocol the semantics of whose state-changing verbs PUT and POST are remarkably well-matched for these interactions whereby a client says please take this and publish it and tell me what you did and the server says OK, here's what I made of it. The current WG consensus, way better than rough, is that this level of interoperation is useful. That consensus seems to be supported by implementation experience. Lisa, perhaps the problem is that I'm reacting to a fairly general statement of concern. Do you have some specific suggestions as to how server behavior could be limited or formally described? -Tim
Re: Atom Entry docs
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 -Tim 1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get them defined, registered, and ready to use.) 2) Leave RFC4287 unchanged. i.e. do NOT re-define application/atom-xml 3) New specifications MAY require that ;type=entry be used. (Note: Just because ;type=entry is used DOES NOT imply that ;type=feed must also be used) Thus, APP would accept application/atom+xml when looking for a feed but might insist that entries be explicitly identified with a disambiguating type parameter. Thus, no code which currently uses application/atom+xml to designate a feed would be broken. Additionally, any code which is properly built and thus ignores unknown types will not be hurt when it sees application/atom+xml;type=entry since it will ignore the type parameter and dig around inside the data to figure out if it is feed or entry. The only code which will be hurt is some potential code that does not follow the existing RFCs for Atom or mime types. It is, I think, OK to occasionally break code that doesn't follow the specs. Whatever the technical arguments may be, I believe it is important from a political point of view that we do not change the definition of things defined in Atom. I am all for extending Atom, but not for changing Atom. We must not change the exiting specification unless there is some really serious harm being done. If we do, we risk losing the trust of at least some members of the community that we've built these last few years... Folk will remember that one of the advantages that is claimed for RSS is that it has been declared to be eternally free from modification. While I personally believe that that is silly, the proponents of RSS do have a point when they speak of the value of stable specs. If we allow the Atom spec to be *changed* so soon after it was accepted and we don't have a really, really good reason for doing it, we will simply have proven the often made claim that standards groups simply can't be trusted with important specifications. We will be encouraging more of the kind of standards making that resulted in the mess that is RSS... bob wyman PS: Since Kyle points out that GData, a Google product, is potentially impacted by the results of this discussion, I should state that I currently work for Google -- although I am not currently assigned to any product or project that has a direct interest in the definition of Atom, APP, etc... My participation in this discussion, at this time, is driven purely by personal interest.
Re: Atom namespace really not ending with / or # ?
Anne van Kesteren wrote: Jan Algermissen [EMAIL PROTECTED] wrote: is it really true that the Atom namespace is http://www.w3.org/2005/Atom ? It wasn't really relevant, I'd say. (That it says Atom and not atom was a mistake.) I'd agree. Sigh. But not a big one, I think -Tim
Re: Atom Entry Documents
Mark Baker wrote: Ok, the recent discussion seems to point towards a consensus towards distinctly flagging Entry Documents in the media type. Erm, isn't it up to the chairs to declare concensus? co-chair-modeI agree that there exists sentiment in favor of there being a way to distinguish between Feed and Entry documents. I think the notion of consensus is only meaningful in the context of actual spec language, so it seems to me that it would be helpful to have some proposed language to look at. So I see no downside in James doing an I-D./co-chair-mode -Tim
Atom Entry docs
I seems obvious to me that Atom Feed and Entry docs are potentially quite different things which can be used for entirely different purposes. The contention that an Entry doc is somehow really the same as a one-entry Feed doc is entirely unconvincing. The Architecture of the Web (http://www.w3.org/TR/webarch) and the TAG finding on Authoritative Metadata (http://www.w3.org/2001/tag/doc/mime-respect.html) make it pretty clear that it's advantageous to use HTTP headers to distinguish between different kinds of representations. So I guess I'm in favor of us writing something down to address this problem. RFC4287 is now pretty widely implemented, so there is a distinct cost to screwing around with the well-known application/atom+xml. On the other hand, my perception is that virtually all software that knows about 4287 knows about feeds, rather than entries. Thus, it seems to me that introducing a parameter so that existing software might see application/atom+xml;type=feed *might* break some software. But introducing a new media-type application/atom-entry+xml which only goes with standalone feed documents is very unlikely to break anything. So I'm for James' option B) application/atom-entry+xml (James, did you really mean atom.entry with the ugly dot?) -Tim
Re: PaceEntryMediatype
On Nov 29, 2006, at 8:16 AM, James M Snell wrote: http://www.intertwingly.net/wiki/pie/PaceEntryMediatype #pragma section-numbers off == Abstract == For the current Atom Publishing Protocol draft... Irrespective of the merits of the new media type, the APP spec seems like the wrong place to define it. Since nobody wants to obsolete 4287, why not a short clean standalone I-D? -Tim
Re: PaceAutoDiscoveryDraftIsPointless (was: PaceMakeAutodiscoveryInformational)
On Nov 28, 2006, at 3:16 PM, Robert Sayre wrote: They already know how, in general. The WHAT-WG is the place to work out edge cases in HTML semantics. Over the course of history, a remarkable number of different groups have jumped up and down and said *We're* the ones defining HTML!!! Listen to *us*!!!. It's foolish to draw conclusions about any HTML- related spec based either on which group is originating it or what anyone claims the browser engineers are going to do. -Tim
Re: Author element best practice
On Nov 22, 2006, at 3:11 AM, Sylvain Hellegouarch wrote: Say I POST an atom:entry to a collection URI, this entry does not have an atom:author If I were implementing the server, in this scenario I'd reject the post with an error message. It's hard for me to see a scenario where the author info isn't already known and not providing it is still OK. (In fact, it's hard for me to imagine a scenario in which the author info isn't already known, period.) -Tim (which could be considered as not valid but that's not the question here), now say that my app server does not have any information as to what value to set when adding the atom:author element to the member, do you think it'd be better to put an empty atom:name or to put a dummy value such as 'anonymous' or 'n/a'? I'm asking because I try to make sure that whatever the input is the member I create are respectful of section 4.1.2 of RFC 4287 and I can't decide which way to go when some information are missing from the context. Any best practices from you guys? Thanks, - Sylvain
URGENT: Remove atom:updated ordering requirement?
co-chair-mode Please see the dialogue below. /co-chair-mode (Eric's point seems plausible to me; personally I'd be inclined to a +1.) co-chair-mode Can we have some feedback from the WG ASAP? We want to take protocol-11 to the IETF. /co-chair-mode -Tim On Sep 26, 2006, at 4:59 PM, Eric Scheid wrote: On 27/9/06 8:15 AM, Tim Bray [EMAIL PROTECTED] wrote: PaceAppEdited: Lots of discussion. There seems universal support for the utility of an app:edited element, and an assertion that entry members SHOULD contain one. On the other hand, every discussion of sort order has spiraled instantly into a rat-hole. Conclusion. PaceAppEdited is accepted, in part. The second part of the proposal, defining the app:edited element, is ACCEPTED. The first part, imposing a requirement on the sort order of collections, clearly does not have consensus support. There also seems to be universal support for the notion that collection feeds could be sorted by something other than what's currently in the spec. The spec currently not only says collections are to be sorted by atom:updated, but because of the MUST it also says it MUST NOT be sorted by anything *else*, which is a problem. Section 10.0 ¶ 2 says this: The entries in the returned Atom Feed MUST be ordered by their atom:updated property, with the most recently updated entries coming first in the document order. Clients SHOULD be constructed in consideration of the fact that changes which do not alter the atom:updated value of an entry will not affect the position of the entry in a Collection. We need to either strike that entire paragraph, or at the very least make that MUST into a SHOULD. I say +1 to s/MUST/SHOULD/ e.
Re: WG Last Call for draft-ietf-atompub-protocol
On Sep 26, 2006, at 12:34 PM, Sam Ruby wrote: Here's a list of Paces that weren't disposed of with the last consensus call: First of all, did Sam get them all? Please speak up soonest about anything that was missed and might have a realistic chance. co-chair-mode PaceAppEdited: Lots of discussion. There seems universal support for the utility of an app:edited element, and an assertion that entry members SHOULD contain one. On the other hand, every discussion of sort order has spiraled instantly into a rat-hole. Conclusion. PaceAppEdited is accepted, in part. The second part of the proposal, defining the app:edited element, is ACCEPTED. The first part, imposing a requirement on the sort order of collections, clearly does not have consensus support. = PaceAppEdited2: Not enough support, some opposition, big and complicated. REJECTED. = PaceAppModified3: Lots of discussion, no real consensus, eventually replaced by PaceAppEdited. REJECTED. = PaceAppVersion: Got no +1s, some opposition: REJECTED. = PaceCollectionLinkType: zero discussion: REJECTED. = PaceFixModel: 2 supporters, not enough: REJECTED. But note that this is inconsistent with some of the language in section 9, so editorial work is required. = PaceLocationPointsToEntry: zero discussion: REJECTED. = PaceOrderCollectionsByAppModified2: zero discussion: REJECTED. = PaceRemoveConnegSuggestionOnServiceDoc: almost no discussion: REJECTED. = PaceRemoveOutOfLineCategoriesFromCategoryDocument: 2 supporters, little discussion, not enough. REJECTED. = PaceRevertTitle: Lots of -1's: REJECTED. = PaceSecurityConsiderationsRevised: We need something in the Security Considerations section of the document, and there was at least some support for the ideas in this section in the past. The other proposal for words for this section was withdrawn. Therefore, this Pace is ACCEPTED with the understanding that the issue of what our security considerations are is not closed and may be modified after the IETF last call. = PaceServiceLinkType: Not enough discussion/support: REJECTED. = UseElementsForAppCollectionTitles3: Seems to have been incorporated in the draft. /co-chair-mode
Re: Private extensions and relation to atom elements
On Sep 11, 2006, at 4:27 AM, James Aylett wrote: We've run across a situation where we want to annotate an atom:icon with a title. Currently we're doing the following, as something that Feed Validator is happy with, but doesn't feel right: -- atom:iconuri:to/icon/atom:icon myns:icon-title xml:lang='en' xmlns:myns='...'My icon title/myns:icon-title let's assume myns: is declared. Then why not icon myns:buddha-nature=high myns:sizzle=lowicon-uriicon -Tim
Re: Private extensions and relation to atom elements
On Sep 11, 2006, at 7:45 AM, James Aylett wrote: Feed Validator gets upset with extension attributes - is it wrong? Be specific, please? -Tim
Re: atom:updated - not now() values?
Eric Scheid wrote: When updating an entry, is it acceptable to insert a value other than Now() into atom:updated? Clearly, since updated is defined as the time the publisher thinks it was significantly updated. Of course, the server could over-write the updated value if it chose. -Tim For example: Corporate Communications prep a release and they stamp it with a release date of Monday 4 PM ... but I don't see this release update until I get into the office at 2 PM Tuesday, and thus I quickly enter it into the CMS and set the atom:updated value to Monday 4 PM. e.
Re: Link rel test cases
On May 30, 2006, at 5:25 PM, James Holderness wrote: I agree completely, but as a content consumer I still need to know whether to use IRI::Compare or String::Compare when I do encounter some ridiculous feed that uses example (a). I'm hoping for a simple answer along the lines of Use IRI:Compare, Use String::Compare, or The spec doesn't say, so you may use whatever you prefer. Both are perfectly legal. IRI::Compare will avoid some false negatives at the cost of burning some CPU cycles. Postel's law would suggest using IRI::Compare initially, but if a profiler revealed it to be a performance bottleneck, I'd nuke it in favor of strcmp() without a second's hesitation. I actually wouldn't be surprised if that happened; case-insensitivity and Unicode sit poorly together and are a notorious source of performance sinkholes. -Tim
Re: Feed Thread in Last Call
On May 17, 2006, at 12:46 PM, Byrne Reese wrote: Speaking up: http://www.majordojo.com/atom/ standardizing_the_atom_thread_extension.ph p No surprise I guess, but I am a huge +1. Lock this spec down and ship it. Me too. Does something useful, does no harm, if it's broken in some way it'll be harmlessly routed around. I suspect that implementations that are stupid about the contents of atom:link will be fixed pretty soon. -Tim
Re: Feed Thread in Last Call
On May 18, 2006, at 6:15 AM, David Powell wrote: What I see as a problem is that reasonable implementations will not preserve Atom documents bit-for-bit, so they will need to explicitly support this draft if they don't want to corrupt data by dropping the thr:count attributes. By the letter of RFC4287 there is no problem with the draft, but practically there is something like a layering concern if an extension requires existing conformant implementations to be changed. At the end of the day, the marketplace will work within the constraints of what 4287 allows; my feeling is that there are going to be a ton of extensions that will attach unforeseen metadata at arbitrary points with Atom documents, and implementations that fail to store these and make them retrievable will quickly be seen as broken. -Tim I notice that you said implemented support - that is fine for user-agents etc, but I don't believe that Atom infrastructure should be required to implement support for each new bit of content that publishers put into their feeds. On the contrary; I think that implementors who fail to deal with the fact that people will be adding their own non-Atom stuff at every conceivable place in an Atom feed are being very stupid, because this will happen whatever we say. -Tim
Re: Feed Thread in Last Call
On May 20, 2006, at 8:49 AM, David Powell wrote: (at great length) I'm going to re-organize David's argument a little and deal with one of his last points first. Foreign attributes are bad, and are inherently less interoperable than Extension Elements. I would say that furious debates about elements-vs-attributes have been going on since the dawn of XML in 1998, but that would be untrue; they've been going on since the dawn of XML's precursor SGML in 1986. They have never led anywhere. After you've noticed that if you need nested element structure you're stuck with elements, and if you don't want to have two things with the same names attributes can help, there really aren't any deterministic decision procedures. I note with pleasure that *all* known XML APIs allow you to retrieve elements and attributes with about the same degree of difficulty. So, my conclusion: I disagree with Powell. Let people put extensions wherever they feel like putting them (they will anyhow), remembering that human-readability is a virtue. If models try to micro-manage the element/attribute thing, those models are broken, don't use them. If software arbitrarily discards markup because the markup doesn't match its idiosyncratic ideas about elements and attributes, that software is non-comformant and non-interoperable. Software that deals with XML such as an XHTML document, doesn't have much choice but to model the document using generic XML concepts and tools - Infosets, DOM, SAX, strings containing XML tags, etc. For Atom though, it is useful to model feeds and entries in terms of some other data model: OO, RDBMS, WebDAV (I've been doing it as RDF, but that is a dirty word around these parts). Well yes, but each and every one of those non-XML models fails to capture the information content of perfectly-legal XML in one way or another. The Atom data format *could* have been designed in such a way as to be conformant with one or more of those models, but it wasn't. Extensions to Atom can be designed in such a way as to fit into some particular data model, or not. So I think it's really questionable to try to normatively reverse engineer the WG consensus to try to pretend that Atom documents can usefully be processed as anything but XML. Section 6 of RFC4287 is flawed. It is an ugly mix I agree. In fact, what Simple Extension *really* says is this property can trivially be modeled in RDF and Structured Extension really says is doesn't directly map to RDF, but I failed to convince the WG either to remove this hand-waving or to be clear about what we really meant. Having said that, these notions fortunately have exactly zero normative effect on implementors. of my (overly) strict PaceExtensionConstruct proposal[1], and an (overly) liberal philosophy that the existence of foreign markup anywhere won't break implementations, so shouldn't be disallowed. I have no comment on your proposal, but the philosophy you describe does in fact represent the consensus of the WG and the IETF community; your opinion that it is overly liberal is interesting but not particularly relevant to implementors. atompub's charter states: Atom consists of: * A conceptual model of a resource * A concrete syntax for this model Extension elements are defined to have both a model and a syntax, but Atom's allowance for foreign attributes to appear anywhere is a case of syntax that has no corresponding model. Atom doesn't really explain what foreign attributes are intended for. Extension elements also, as noted above, have *no normative effect*. It is arguable that the design of Atom departed from the charter in that the model was never explicitly specified. To me, this seems like sound design; the success of the Web has been based on careful specification of the content and sequence of the interchanged messages without any attempt to standardize on a model. This is A Good Thing, and demonstrably works. And Atom also doesn't really explain what foreign elements are intended for either. It seems like they could be an extension point, but given that many implementations will have an application model that isn't based on the XML Infoset (as described above), There's a word for implementations (especially intermediaries, as you notice) that aren't based on the Infoset: broken. Because RFC4287 is explicitly defined only in terms of the infoset. Go ahead and try to impose any models that are appropriate for your application needs; I do this all the time. But don't change the Infoset. it seems very unwise to create an extension proposal which depends on the precise syntax of an element being preserved. The precise syntax claim is utterly bogus. RFC4287 properly standardizes at the Infoset level, thus it makes zero difference whether I say titleCafé/title or titleCaf#xe9;/title. I personally think that an extension
Re: Feed thread update
On May 4, 2006, at 3:43 PM, Thomas Broyer wrote: Things would have been far easier if either a) atom:link were extensible This assertion that atom:link is not extensible is simply, flatly, completely, wrong. I just went and reviewed 4287 and I think it is perfectly clear on this. I suggest that interested parties review sections 4.2.7, 6.3, and 6.4 and, if they still think there is any problem with child elements of atom:link, find language in the RFC which says something other than what those sections say. -Tim
Re: Feed thread update
On May 4, 2006, at 5:25 PM, Kyle Marvin wrote: the motivation behind sometimes using 'extensionElement' and other times 'undefinedContext' in the Relax-NG schemas for various 4287 elements is a point of confusion. Agreed. Fortunately the schema's non-normative. -Tim
Re: Feed thread update
On May 4, 2006, at 5:08 PM, A. Pagaltzis wrote: The assertion is not that atom:link may not have child elements or namespaced attributes. The assertion is that the list of locations for Metadata elements in Section 6.4 should have included atom:link. Mountain, meet molehill. If it turns out to be useful, it'll stick. Otherwise not. -Tim
Re: Does xml:base apply to type=html content?
On Mar 30, 2006, at 9:20 PM, James M Snell wrote: I would agree that, as a best practice, the xml:base should appear on the content element, but implementations need to be prepared to use whatever the in-scope URI is (e.g. if no xml:base is specified, relative refs in the content will be relative to Content-Location or the feeds Request URI). Maybe. Highly error-prone. In other words, consumers of the feed *have* to assume that the current xml:base in context is going to be correct and publishers of the feed simply have to be responsible for Doing The Right Thing. Agreed. I think providing an xml:base in your feed is a best practice. -Tim
Re: atom:name ... text or html?
On Mar 23, 2006, at 8:01 AM, Sylvain Hellegouarch wrote: Seriously though, the atom:name element is described as a human- readable name, Do you mean that human-readable is equivalent to solely English? Because as a French, having accents in names is so natural that I see it as human readable too ;) You can have accents, you just can't use HTML entities to get them. -Tim
Re: atom:name ... text or html?
On Mar 23, 2006, at 8:57 AM, Eric Scheid wrote: On 24/3/06 3:21 AM, Anne van Kesteren [EMAIL PROTECTED] wrote: authorname![CDATA[Bertrand Cafeacute;]]/name/author Even if it was HTML you couldn't really use the entity, could you? I think you have to use a character reference or the actual character instead, yes. It's true that XML has only a half dozen or so entities defined To be precise, 5: lt; amp; gt; apos; quot; -Tim
Re: atom:name ... text or html?
On Mar 23, 2006, at 8:16 AM, Eric Scheid wrote: If I have an author with the name Bertrand Café, is it acceptable to put that into atom:author like this; authorname![CDATA[Bertrand Cafeacute;]]/name/author or should I be using the unicode numeric entity instead? The key point is that the atom:name element, described in RFC4287 3.2.1, is not a Text Construct, as defined in 3.1, so you can't say atom:name type=html; so no markup allowed. So just say Bertrand Café. -Tim
Re: atom:name ... text or html?
On Mar 23, 2006, at 2:20 PM, Eric Scheid wrote: Oh well, now to track down a list of html entities and their corresponding unicodes ... http://www.google.com/search?q=xhtml%20entities
Re: IE7 Feed Rendering Issue
On Mar 9, 2006, at 7:51 AM, Sean Lyndersay wrote: I hope this helps make the reasoning behind IE’s behaviour with feeds and stylesheets a little less murky. I don't really have an opinion as to whether this is the ideal behavior. But there is no doubt whatsoever that that Sean's software is entirely within its rights. It is almost never possible nor desirable for the transmitter of a general-purpose data format like most of those based on XML to try to impose behavior on the recipient. In the big picture, this is one of the big advantages of open data formats. -Tim
Atom logo where?
Where can one go to get versions of the atom logo (the one in view at atomenabled.org) in various sizes? -Tim
Re: Atom logo where?
On Mar 6, 2006, at 12:43 PM, Anne van Kesteren wrote: Quoting Tim Bray [EMAIL PROTECTED]: Where can one go to get versions of the atom logo (the one in view at atomenabled.org) in various sizes? -Tim I guess SVG fits that definition: http://zcorpan.1go.dk/sandbox/svg/atom/.xml Oooh, now that is *cool*. -Tim
Re: [rss-public] Microsoft Feeds API Enclosure Test
On Feb 24, 2006, at 3:05 PM, Sean Lyndersay wrote: I'm sure that many people -- on this list in particular -- think that the right thing to do is to normalize to Atom 1.0, instead. Yep, that's certainly one way to think about it. But then I'd be having this same discussion with Dave and with folks on rss- public. :) In short, I'd rather avoid the issue altogether and provide some value to the developers who are using the platform -- which means preventing them from having to learn several different formats to get common data, while allowing them to get access to extensions. Given that Atom 1.0, in practice, is a clean superset of RSS 2.0 (there are things in RSS 2.0 that aren't in Atom, but they are typically not used; see http://www.tbray.org/atom/RSS-and-Atom), the only one that's been through a formal standardization process, and the only that's guaranteed not to change (see IETF rules) this feels a little weird. But it's your API. I will say, though, that there are already a lot of Atom 1.0 feeds and there are going to be more, so it does seem like a basic requirement that your interface be able to model Atom 1.0 accurately without data loss. I assume you agree that a failure to do this would be a bug. -Tim
Re: Browser behaviour
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
Re: Browser behaviour
On Jan 30, 2006, at 12:57 PM, John Panzer wrote: In other words, the application/xml content is a fallback for when users, despite our best efforts, end up looking at XML content inside a web browser. I'd also be happy to make this behaviior browser-dependent so that we serve application/atom+xml to browsers which will display it inline with a style sheet, if there are any. This means that users might possibly end up subscribing to something of type application/xml if they copy and paste URL #3... but we could also make this client dependent so that, for example, everything other than known web browsers get application/atom+xml. Not sure about that as it's changing the MIME type, but I think it's changing it for a good reason (working around what I think is a browser problem). Seems sensible. -Tim
Re: [Fwd: Approval of Atom LinkRelations Attribute Value Registrations]
On Jan 25, 2006, at 11:56 AM, James M Snell wrote: APP should use the values as registered. That is, previous, next, first, last and current. No need to modify the registrations. +1
Re: finishing autodiscovery, like now
On Jan 19, 2006, at 9:05 AM, Robert Sayre wrote: PaceAnchorSupport and PaceDifferentRelValue don't seem very useful, and they weren't proposed by implementors. The spec is extremely well-written and reflects existing behavior. Can we please un-expire this: http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html and be done? +1. Ship it. -Tim -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Reader 'updated' semantics
On Jan 10, 2006, at 9:07 AM, James M Snell wrote: In RSS there is definite confusion on what constitutes an update. In Atom it is very clear. If updated changes, the item has been updated. No controversy at all. Indeed. There's a word for behavior of RssBandit and Sage: WRONG. Atom provides a 100% unambiguous way to say this is the same entry, but it's been changed and the publisher thinks the change is significant. Software that chooses to hide this fact from users is broken - arguably dangerous to those who depend on receiving timely and accurate information - and should not be used. -Tim
Re: Reader 'updated' semantics
On Jan 9, 2006, at 5:08 PM, James M Snell wrote: The updated element is used to indicate when a significant update has occurred to the entry. If you are updating the updated element when you update your entry, you are doing the right thing. If RSSBandit and FeedDemon are not picking up the fact that the entry has been modified based on a changed updated value (even if the updated element is the only thing that is different), then I would say those readers have a bug. You should never be changing your id element value. James is exactly right. The whole reason 'updated' exists is *exactly* so you can tell the downstream software unambiguously when some entry has changed and this ought to be brought to the consumers' attention. -Tim
Re: Tag URIs
On Dec 17, 2005, at 9:01 PM, Alan Gutierrez wrote: I'm to understand that Atom has adopted the Tag URI as a a perferred. GUID for an Atom 1.0 feed. It has not. There is no preferred scheme. -Tim
Re: clarification needed: order of children of atom:entry
On Oct 26, 2005, at 9:46 PM, Eric Scheid wrote: Section 4.1.2 of the Atom Syndication Format spec states this: This specification assigns no significance to the order of appearance of the child elements of atom:entry. Is this referring to the immediate children only of atom:entry, or of all descendents? In the XML context, the term child elements is not ambiguous. So I think it means what it says, which is what you want it to mean. -Tim
Re: New Link Relations -- Ready to go?
On Oct 21, 2005, at 5:03 PM, Mark Nottingham wrote: How about: - Description: A URI that refers to a feed document containing a set of the most recent entries in the feed. This URI is intended to be subscribed to to keep abreast of recent changes in the feed; when different from the URI of the document where it occurs, it indicates that its value should be used for this purpose in place of the current document's URI. For example, an archived feed document might contain a subscribe relation that points to the subscription feed's location, so that clients subscribe to the appropriate link. Note that the self relation was designed for a similar purpose, but is not suitable for that use in other feeds, whereas this relation can be used in those situations. On consideration, I am -1 to rel=subscribe. The reason is this: one of the big potential value-adds Atom brings is a standards- compliant way to do one-click auto-subscribe, via link rel=self / . You are proposing to introduce a link rel=subscribe / which is there to support autosubscribe. But, it turns out, only in the special case where the feed is static and you wouldn't actually subscribe to it. I think the risk of confusing implementors and weakening the value proposition around link rel=self greatly exceeds the benefit of supporting this special case. Plus, I think the thing isn't properly named. It isn't actually subscribe in the general case, it's in the special case where the version you are looking at is static, point to the places where the changes happen because they don't happen here. So, perhaps we should consider rel=current-self or rel=dynamic-version or some such. Finally, markup design that claims to enforce a specific action is always questionable. The great virtue of descriptive markup in general is that the tags tell you not what to do with things but what they are. So on that basis, rel=current-version or something is better design. -Tim
Re: New Link Relations -- Ready to go?
On Oct 22, 2005, at 3:28 AM, Eric Scheid wrote: I think you've got the special case turned around. That is, if you are looking at a representation of the active feed then the 'self' link would happen to match the 'subscribe' link, which is the exception. The defining text in the spec says this about 'self' The value self signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element. atom:[EMAIL PROTECTED]'self'] can also appear in atom:entry, which would be used for pointing to Atom Entry Documents, which explains why the text says the containing element. I don't believe anyone is thinking we should be able to subscribe to Atom Entry Documents. I'm entirely unconvinced. There are two kinds of feed, the dynamic kind and the static kind. For dynamic feeds, use rel=self to subscribe. For static feeds, use some new relationship like rel=dynamic to point to the dynamic version that you might subscribe to. I agree that, in retrospect, the spec should have said that one intended use of rel=self is to support auto-subscribe. I don't think adding on a new link relationship is the right answer. Are we yet in a situation were we have a preponderance of deployed feeds using 'self' to mean 'subscribe'? Actually, that's the wrong question to ask (see below) Well, all the Atom feeds I see use rel=self in the way you'd expect. Are we yet in a situation were we have preponderance of deployed applications that look for 'self' for subscription purposes? Well, no, because we actually don't have that many apps yet that really grok Atom. When they do, and they want to do auto- subscription, Atom is well-equipped to support it. I think we're in the early days of Atom 1.0 adoption, and we can very likely talk up via blogs, articles, etc the idea of subscribe in the general case using @rel='subscribe'. No. We already have a way to do that and don't need to invent another. -1 on rel=subscribe. -Tim (oh, and I should have said, +1 on the rest of those relationships)
Re: New Link Relations -- Ready to go?
On Oct 22, 2005, at 8:40 AM, Mark Nottingham wrote: You seem to be saying that because link/@rel=self was designed for a specific purpose, and even though its definition is quite descriptive (its definition *only* says it should be used to link to the current document; -11 says nothing about subscription) it should be the only way defined to do subscription. Agreed that the description could be better. What I'm actually saying is since we already have a way to do subscription, we don't need to invent another. Also that the problem of pointing from the static/archived version of a feed to the dynamic/subscribable one is a related but different problem, and the one that you ought to be solving. OTOH, I'm happy to make this relation more declarative. How about: - Attribute Value: current - Description: A URI that, when dereferenced, returns a feed document containing the most recent entries in the feed. - Expected display characteristics: Undefined. - Security considerations: Automated agents should take care when this relation crosses administrative domains (e.g., the URI has a different authority than the current document). Thank you. +1 -Tim
Re: New Link Relations -- Ready to go?
On Oct 21, 2005, at 7:38 AM, James Holderness wrote: The idea being that if you were to come across an archived Atom document (however that might happen), the presence of this link would, (a) let you know that it was an archive document and thus shouldn't be subscribed to, and (b) provide you with a URL with which you could subscribe to the actual feed if you so chose. Makes sense, but not self-evident. I would think that the usefulness of this thing would be improved by a few words of explanation for those who come upon it without knowing the history. -Tim
Re: New Link Relations -- Ready to go?
On Oct 21, 2005, at 3:13 PM, Mark Nottingham wrote: - Description: A URI that refers to a feed document containing a set of the most recent entries in the feed. This URI is intended to be subscribed to to keep abreast of recent changes in the feed. When different from the URI of the document where it occurs, it indicates that its value should be used for this purpose in place of the current document's URI. Any suggestions? Yes. Acknowledge the specific case of an archival feed, an example is worth a thousand words. And discuss why this exist when Atom already has link rel=self, specifically designed to support auto-subscribe. -Tim
Re: Question about [EMAIL PROTECTED]
On Oct 7, 2005, at 10:20 AM, Byrne Reese wrote: Are there any good examples of how the [EMAIL PROTECTED] attribute is used? Over at 'ongoing', I have my own set of categories, so my category elements look like category scheme='http://www.tbray.org/ongoing/What/' term='Business' / Remember, it's optional, both for the producer and for the consumer (Technorati, for example, ignores the scheme); but for well-defined taxonomies like Dewey Decimal or whatever, I think it would be a good idea to put a URI there to disambiguate them. -Tim
Re: Atom 1.0 ootb with MT3.2
On Sep 9, 2005, at 5:03 AM, Bill de hÓra wrote: Here's the feedvalidator results for my journal served up as Atom1.0 as per MT3.2's Atom1.0 template http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.dehora.net% 2Fjournal%2Fatom.xml I'm getting a 404 on that (or rather the feedValidator is) -Tim I also see it uses tag: uris as the atom:id value. I think I'll change the template to use the http: URI generated by MT3.2 for the individual entries instead of the tag: (what the rest of the world calls permalinks). I haven't tried to import/export to see if the atom:id is preserved across installations. Speaking of URIs and IDs, there is a gotcha around archive URIs if you are upgrading to MT 3.2 [1]. cheers Bill [1] http://www.dehora.net/journal/2005/09/ did_you_know_that_mt32_clips_the_basename_to_30_chars_by_default_and_i f_youre_not_careful_an_import_will_trash_your_permalinks.html
Re: If you want Fat Pings just use Atom!
On Aug 23, 2005, at 6:57 AM, Bjoern Hoehrmann wrote: That's a bit misleading, a fatal error just means that the XML processor must report the error to the application and that the processor is not required by the XML specification to continue processing; doing so is however an optional feature... No. See, http://www.w3.org/TR/REC-xml/#sec-terminology, under fatal error. -Tim Yes, exactly what I wrote... No. The specification clearly *forbids* proceeding with normal processing. If you get a busted element in a feed, you'd better close that connection and open another one. -Tim
Re: If you want Fat Pings just use Atom!
On Aug 22, 2005, at 9:27 PM, A. Pagaltzis wrote: It's got another advantage. You connect and ask for the feed. You get feed xmlns=http://www.w3.org/2005/Atom; ... goes on forever and none of the entry documents need to redeclare the Atom namespace, which saves quite a few bytes after the first hundred thousand or so entries. -Tim That’s the first really solid pro-single-doc argument I see… There's another. You don't have to create a new XML parser for each of the entries. In most programming environments, that's a time- saver. -Tim
Re: If you want Fat Pings just use Atom!
On Aug 22, 2005, at 9:56 PM, Bjoern Hoehrmann wrote: If you encounter a busted tag on the Nth entry, per the XML spec that's a fatal error and you can't process any more. That's a bit misleading, a fatal error just means that the XML processor must report the error to the application and that the processor is not required by the XML specification to continue processing; doing so is however an optional feature and further processing would be implementation-defined. So this scenario is unconstrained by the XML specifications. No. See, http://www.w3.org/TR/REC-xml/#sec-terminology, under fatal error. -Tim
Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)
On Aug 21, 2005, at 1:42 PM, A. Pagaltzis wrote: * Paul Hoffman [EMAIL PROTECTED] [2005-08-21 21:55]: Ah, I had missed that. This leads to a question for the mailing list. Does an informative extension that appears at the feed level (as compared to in entries) indicate: d) completely unknown unless specified in the extension definition Atom itself has precedent for both b) and c). So I would say it’s d) – but also that aggregators should assume b) when they don’t know any better. Right, the only possible answer. -Tim
Re: If you want Fat Pings just use Atom!
On Aug 22, 2005, at 7:26 AM, Joe Gregorio wrote: 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. Ahh, I had thought this was a more dedicated ping traffic stream. The never ending Atom document makes much more sense now. It's got another advantage. You connect and ask for the feed. You get feed xmlns=http://www.w3.org/2005/Atom; ... goes on forever and none of the entry documents need to redeclare the Atom namespace, which saves quite a few bytes after the first hundred thousand or so entries. -Tim
Re: Feed History -03
On Aug 17, 2005, at 4:10 AM, Henry Story wrote: Yes. I agree the problem also exists for complex extensions. My question is the following: How can a parser that parses atom and unknown extensions, know when to apply the xml base to an extension element automatically? It can't. Anyway to summarise: if you don't want to use the atom:link element then perhaps it would be best to use the xlink:link attributes. I have only read that spec quickly [1] but this would mean that the following fh:history xlink:href=./archives.archive1.atom That would work. I haven't been following this discussion closely enough to understand why there's resistance to atom:link rel=some- history-thing ... -Tim
Re: xml:base abuse
On Aug 15, 2005, at 7:28 AM, Tim Bray wrote: The way Tim Bray's feed and the examples from James Snell on developerWorks use xml:base is what Roy T. Fielding calls an abuse. I disagree with Roy, but agree that the way my links were set up was a little surprising to the eye, so I tweaked. Check out http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.tbray.org% 2Fongoing%2Fongoing.atom -Tim
Re: Spec explanations for Pebble?
On Aug 13, 2005, at 1:34 AM, Simon Brown wrote: Just to quote an example, Tim is currently using URL based Atom IDs, such as : idhttp://www.tbray.org/ongoing//id idhttp://www.tbray.org/ongoing/When/200x/2005/08/09/Web-2.0/id If Tim *moves* his blog to www.timbray.com/ongoing, would you expect his Atom IDs to remain the same? Absolutely, otherwise everyone who subscribes to me is going to see all the same old articles again, exactly what atom:id exists to prevent. The fact that I use HTTP URIs for identifiers reflects my belief that good Web citizenship requires that once something is published and its URI widely disseminated, it should never ever be moved; so in my case this scenario is unlikely to arise. -Tim
Re: Spec explanations for Pebble?
On Aug 12, 2005, at 1:55 AM, Graham Parks wrote: categorization scheme means the system used to categorize entries. Presumably each blog has its own system for doing so, so the scheme attribute should be the same for all posts from the same blog, and unique to the blog. Mostly agree. Except for, a bunch of blogs might agree to share a categorization scheme, so probably not unique to each blog. But I suspect that the notion of categorization scheme is underdefined enough that if someone wanted to use different URIs for each page like the example Carey cited, that's really dumb but not actually illegal. -Tim
Re: More about Extensions
On Aug 9, 2005, at 5:11 PM, David Powell wrote: No, we just need to warn publishers (and extension authors) that the base URI of Simple Extension elements is not significant, and that they must not expect it to be preserved. Either the software understands the foreign markup, in which case it might recognize a relative URI, in which case it should apply the correct base URI, or it doesn't, in which case everything in the foreign markup is just a semantics-free string. The problem could hypothetically arise when someone extracts properties from the foreign markup, stuffs them in a tuple store, and then when the software that knows what to do with comes along and retrieves it and recognizes the relative URI and can't do much because the base URI is lost. So... IF you know how to handle some particular extension, AND IF you expect to handle it when the extension data has been ripped out of the feed and stored somewhere without any context, THEN you shouldn't use a relative reference. Alternatively, IF you want to empower extensions to process they data they understand, AND IF you want to rip that data out of the feed and store it somewhere, THEN it would be smart to provide software an interface to retrieve context, such as feed-level metadata and the base URI. Sounds like implementor's-guide material to me. And, to whoever said relative references are fragile: Wrong. When you have to move bales of web content around from one place to another, and just supposing hypothetically that you have internal links, relative references are robust, absolute URIs are fragile. -Tim
Re: spec bug: can we fix for draft-11?
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
Re: spec bug: can we fix for draft-11?
On Aug 3, 2005, at 6:04 AM, Sam Ruby wrote: To an Infoset person, this following is a completely different stream from the example above (please ignore any line breaks that your email client may insert): atom:id#104;#116;#116;#112;#58;#47;#47;#101;#120;#97;#109 ;#112;#108;#101;#46;#99;#111;#109;#47;#102;#111;#111;/ atom:id I believe this is incorrect, see http://www.w3.org/TR/xml-infoset/ #omitted, item 6 Infoset views the below two examples as different: atom:id![CDATA[http://example.com/foo]]/atom:id atom:idhttp://example.com/foo/atom:id I believe this is incorrect, see http://www.w3.org/TR/xml-infoset/ #omitted, item 19 Or am I missing something obvious? -Tim
Re: Comments Draft
On Aug 4, 2005, at 10:59 PM, Eric Scheid wrote: link rel=in-reply-to href=http://www.example.com/atom; type=application/atom+xml thread:idref=urn:foo:1 / this way processors that have a basic understanding of what a link is can still do something useful. Uh, consider link rel=ultimate-source-of-all-evil-STAY-AWAY href=http://example.org/evil; / What useful thing is there that software could sanely do, knowing only that something is a link? -Tim
Re: Simple Extensions and xml:base
On Aug 5, 2005, at 5:59 AM, David Powell wrote: We say that Simple Extension Elements are not language sensitive, but They *are* affected by xml:base. xml:base establishes the base URI for wherever it's in-scope, with a specific callout to RFC3986 for the semantics. Anytime you see something that you know is a relative URI reference, you have to absolutize it using the base URI, and the base URI is what xml:base says it is. -Tim Yes, I understand, but I disagree. xml:base only affects things that are designated to be URI references. I wouldn't expect atom:title/index.html/atom:title to get resolved as a URI, because atom:title isn't defined to be a URIRef. Neither are Simple Extension Elements. Right, but anyone who reads a simple extension out of an Atom feed and finds something they consider to be a relative URI reference, and wants to absolutize the reference, either uses the base URI as established by xml:base, or they are wrong. -Tim
Re: spec bug: can we fix for draft-11?
On Aug 4, 2005, at 3:25 AM, Paul Hoffman wrote: At 7:37 PM -0400 8/2/05, Robert Sayre wrote: One way of saying this would be Atom Processors MAY ignore leading and trailing whitespace in _. That works for me. Another idea is Atom Processors MAY ignore leading and/or trailing whitespace in elements whose content does not allow leading and/or trailing whitespace, such as IRIs and . The more I think about this family of suggestions, the less I like them. There is no coherent argument from the published specifications of XML and IRIs that allows our 4.2.6 language Its content MUST be an IRI to regard atom:id http://example.com/foo /atom:id as anything but an error. I suggest an alternate formulation: === Implementors are advised that there is a common class of error in which, when the content of an element is specified as being an IRI, software which generates Atom documents introduces spurious white space before and after the IRI, for example: atom:id urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6 /atom:id In this case, since [RFC3987] makes it clear that the leading and trailing white space cannot be part of the IRI, implementors MAY choose to be forgiving in regards to this error, by ignoring the leading and trailing white space. === I'm strongly -1 on treating this as anything but an error. We may at our discretion make it forgiveable. This formulation would also allow the feed validator to complain. I suppose if we did this, we should generalize it slightly to apply to date constructs as well. -Tim
Re: spec bug: can we fix for draft-11?
On Aug 4, 2005, at 6:53 AM, Robert Sayre wrote: I propose trying harder, but I am open to just fail. As am I. I am not OK with a long treatise on whitespace, like the one Tim suggested. If there is a MUST-breaking error in a feed, that's not an Atom document and I don't want to talk about it. I slightly prefer documenting and allowing what the world's PHP scripts have been observed to produce, but either way is fine. BTW, my proposed text was taken from HTML 4.01. 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. So my preferred course of action would be to leave it the way it bloody well is. The Feed validator should throw whitespace-polluted pseudo-Atom on the floor, and if some bozos persist in producing it, and some implementors decide to work around this error, well, that's the way the Internet is. But if a couple of leading implementations decide to be strict, and the producers develop a culture of Doing The Right Thing, well then, that's the way the Internet is too, sometimes. PHP is, if nothing else, flexible and friendly to quick changes in deployed scripts, I can hear a zillion publishing-system hackers grumbling Oh, it's that damn tight-assed Atom stuff, guess I have to use mod_finicky here. So for now, I'm -1 on an weakening or removing The element's content MUST be an IRI or analogous text in any other section. I'll stop shouting if I'm in a small minority here. -Tim
Re: spec bug: can we fix for draft-11?
On Aug 2, 2005, at 4:37 PM, Robert Sayre wrote: One way of saying this would be Atom Processors MAY ignore leading and trailing whitespace in _. That is, no existing software is buggy, but if you want to be sure your document is processed accurately, you should trim the space yourself. Ecch. Blecch. Barf. I suppose. I personally think the framework of specifications is crystal-clear, and per the letter of the law atom:id http://example.com/foo /atom:id is totally illegal because the string \nhttp://example.com/foo\n does not conform to the productions for either URI or IRI. I am less convinced that people are actually going to do this, but I do agree that if a substantial number *do* do this, implementors will simply ignore us and code around it. So if the WG really thinks this is a sensible clarification I won't scream too much. -Tim
Atom 1.0 xml:base/URI funnies
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 updated2005-07-16T11:17:23-08:00/updated authornameTim Bray/name/author subtitleongoing fragmented essay by Tim Bray/subtitle idhttp://www.tbray.org/ongoing//id rightsAll content written by Tim Bray and photos by Tim Bray Copyright Tim Bray, some rights reserved, see /ongoing/misc/ Copyright/rights generator uri='misc/Colophon'Generated from XML source code using Perl, Expat, XML::Parser, Emacs, Mysql, and ImageMagick. Industrial strength technology, baby./generator entry xml:base='http://www.tbray.org/ongoing/When/200x/2005/07/14/' titleAtom 1.0/title link href='Atom-1.0' / idhttp://www.tbray.org/ongoing/When/200x/2005/07/14/Atom-1.0/id published2005-07-14T13:00:00-08:00/published updated2005-07-16T11:17:12-08:00/updated category scheme='http://www.tbray.org/ongoing/What/' term='Technology/Atom' / summary type='xhtml'div xmlns='http://www.w3.org/1999/xhtml'It’s cooked ... eliding ... content type='xhtml'div xmlns='http://www.w3.org/1999/xhtml' ... eliding ... img class=inline src=Atom.png alt=Atom/
Re: Atom 1.0 xml:base/URI funnies
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. 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? I was actually going to propose that very thing. I think it would be highly useful. -Tim
Re: Atom 1.0 xml:base/URI funnies
On Jul 16, 2005, at 11:20 AM, 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. Hey hey hey, it turns out xml:base is supposed to stack. Thus. 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' / ... entry xml:base='When/200x/2005/07/14/' titleAtom 1.0/title link href='Atom-1.0' /
The Atomic age
Paul assures me that the remaining IETF process steps will not introduce material technical changes, and so format-10 is appropriate as a basis for implementors to go to work. So, implementors... to work. And everyone, now is a good time to tell the world. -Tim
Re: The Atomic age
On Jul 15, 2005, at 8:56 AM, Walter Underwood wrote: --On July 14, 2005 11:37:05 PM -0700 Tim Bray [EMAIL PROTECTED] wrote: So, implementors... to work. Do we have a list of who is implementing it? That could be used in the Deployment section of http://www.tbray.org/atom/RSS-and-Atom. Good idea. Ultraseek will implement Atom. We need to think more about exactly what it means for a search engine to implement it, but we'll at least spider it. Want to write a few words in web-space somewhere, Walter, and we can put that in the Wiki? -Tim
Re: The Atomic age
On Jul 15, 2005, at 12:35 PM, Robert Sayre wrote: http://feedvalidator.org/check.cgi?url=http%3A%2F% 2Fwww.fondantfancies.com%2Fblog%2Fatom1%2F Hmm... the feed looks OK to me; I wouldn't be surprised if it's tickling a bug in the just-barely-into-beta Atom 1.0 feedvalidator code. -Tim :) Robert Sayre On 7/15/05, Graham [EMAIL PROTECTED] wrote: On 15 Jul 2005, at 4:56 pm, Walter Underwood wrote: Do we have a list of who is implementing it? That could be used in the Deployment section of http://www.tbray.org/atom/RSS-and- Atom. My blog has one here: http://www.fondantfancies.com/blog/atom1/ I think it's valid, though it's hard to tell without a validator or even a parser. I'm currently rewriting the engine of Shrook to be compatible too. (You may also notice I'm doing my little bit to make sure atom:id is implemented properly) Graham Parks
Atom format progress
co-chair-mode The Atom Format draft was considered by the IESG today, and there remain some outstanding DISCUSS issues, see: https://datatracker.ietf.org/public/pidtracker.cgi? command=print_ballotballot_id=1681filename=draft-ietf-atompub-format https://datatracker.ietf.org/public/pidtracker.cgi? command=view_iddTag=11964rfc_flag=0 We need a format-10 draft to incorporate solutions to these; Rob and Mark are on it. The WG has seen all the currently-planned changes, so -10 should have no surprises. Paul is working (a huge amount, you'd be astounded) on interfacing to the IESG. Stand by. -Tim /co-chair-mode
Re: Major backtracking on canonicalization
On Jul 6, 2005, at 3:28 PM, Paul Hoffman wrote: Greetings again. I gravely misunderstood XML Canonicalization, and as it has been explained to me now, XML Canonicalization would be a disaster for Atom: what we want is Exclusive XML Canonicalization. Urgh, I should have caught this. Correct. +1 -Tim
Re: Roll-up of proposed changes to atompub-format section 5
On Jul 5, 2005, at 8:58 AM, Bob Wyman wrote: We can debate what it means to have an interoperability issue, however, my personal feeling is that if systems are forced to break and discard signatures in order to perform usual and customary processing on entries that falls very close to the realm of interoperability if not within it. Deferring this issue until the implementer's guide is written is likely to defer it beyond the point at which common practice is established. The result is likely to be that intermediaries and aggregators end up discarding most signatures that appear in source feeds. Huh?! Pardon my ignorance, could you please provide an explanation for the simple-minded as to how the absence of a source element in a signed entry will lead to signatures being discarded? Also, it would be helpful to sketch in some of the surrounding scenario... -Tim
Re: Roll-up of proposed changes to atompub-format section 5
On Jul 5, 2005, at 9:27 AM, James M Snell wrote: Huh?! Pardon my ignorance, could you please provide an explanation for the simple-minded as to how the absence of a source element in a signed entry will lead to signatures being discarded? Also, it would be helpful to sketch in some of the surrounding scenario... -Tim Bob can clarify exactly what he means but from my perspective it comes down to an aggregation problem. If a signature is generated over an entry that does not contain an author element or a source element, that entry cannot be re-enveloped into an aggregate feed that does not contain a top level author element without breaking the signature Well, yes. Anyone who understands digsig, even someone such as myself with only a surface knowledge, can see this. You can't change a signed object without breaking the sig, that's the point. If I want to sign an entry and also want to make it available for aggregation then yes, I'd better put in an atom:source. But this is inherent in the basic definition of digsig; not something we need to call out. -Tim
Re: Roll-up of proposed changes to atompub-format section 5
On Jul 5, 2005, at 12:50 PM, Walter Underwood wrote: I'm fine with the delay. Two or three weeks on top of 18 months is not a big deal. I am *not*. It's not two or three weeks, it's some uncontrollable time in the future versus now. We have spent way too long already. -Tim
Re: Roll-up of proposed changes to atompub-format section 5
On Jul 5, 2005, at 1:05 PM, David Powell wrote: Will we still be fixing some of bugs raised since the last draft though? Definitely. A number of things have been pointed out as bugs, there's been no WG pushback on any of them, and since we were going to have to have a -10 draft anyhow for the namespace, we will roll in those fixes, as well as resolving any IESG-raised issues. -Tim Specifically, what are the resolutions for the disputed ban on composite MIME types [1], and some of the specific bugs in section 6 [2] (mismatches with the RelaxNG etc)? [1] http://www.imc.org/atom-syntax/mail-archive/msg15911.html [2] http://www.imc.org/atom-syntax/mail-archive/msg15915.html -- Dave
Re: Roll-up of proposed changes to atompub-format section 5
On Jul 5, 2005, at 4:08 PM, Paul Hoffman wrote: Intermediaries such as aggregators may need to add an atom:source element to an entry that does not contain its own atom:source element. If such an entry was signed, the addition will break the signature. Thus, a publisher of individually-signed entries should strongly consider adding an atom:source element to those entries before signing them. Grumble grumble OK. -Tim
Re: Roll-up of proposed changes to atompub-format section 5
On Jul 4, 2005, at 7:38 PM, Bob Wyman wrote: I believe it would be very useful to specify that signed entries should include a source element. This can/should be considered part of entry canonicalization. -1. Leave it to the market. I suspect that you're right, but I'd be unsurprised if an application for signed un-sourced applications turned up. -Tim The reason I suggest this is that signed entries are only really useful when extracted from their original source feeds. If entries are only read from their source feeds, then it is probably best for publishers to sign the feed, not the individual entries. (Note: It is my hope that feed publishers will anticipate that their entries will be extracted from the source feeds and will thus sign the individual entries rather than the feeds... i.e. Publishers should anticipate that intermediaries like PubSub and various other search/ discovery services will aggregate their entries and republish them in non-source feeds.) When an entry is removed from its source, it SHOULD have a source element inserted if one is not already present. However, if a republisher inserts a source element into a signed entry that would break the signature. Thus, it seems reasonable that we should strongly encourage those who sign entries to anticipate the needs of subsequent processors by inserting the source elements in the original signed entries. By inserting the source elements, the requirement for others to break the signature will be drastically reduced. If an entry is signed, yet contains no source element, much of the utility of the signature (allowing verification of the original publisher) is eliminated. bob wyman
Re: Clearing a discuss vote on the Atom format
On Jun 30, 2005, at 6:26 PM, Paul Hoffman wrote: Greetings again. Russ Housley, one of the two Security Area Directors, has placed a discuss vote on the Atom format document. You can read it at https://datatracker.ietf.org/public/ pidtracker.cgi?command=view_commentid=36890. Fortunately, it seems reasonably easy to clear this discuss. I'm +1 on Paul's changes. One editorial comment: To be added near the beginning of Section 5 of atompub-format: Producers of feeds and/or entries, and intermediaries who aggregate feeds and/or entries, may have sound business reasons for signing and/or encrypting otherwise-unprotected content. For example, a merchant might digitally sign a message that contains a discount coupon for its products. A bank that uses Atom to deliver customer statements is very likely to want to sign and encrypt those messages to protect their customers' financial information and to assure the customer of their authenticity. Intermediaries may want to encrypt aggregated feeds so that a passive observer cannot tell what topics the recipient is interested in. There are hundreds of other reasons why Atom documents might be signed, encrypted, or both. I'd cut this back to one sentence saying. There are many application scenarios where Atom users will wish to apply digital signature, encryption, or both to Atom documents. The examples are non-comprehensive now and will probably look hopelessly quaint before too long. But if people prefer Paul's language I can live with it. -Tim
Re: IESG defers discussion of the format document for two weeks
On Jun 23, 2005, at 7:18 AM, Paul Hoffman wrote: In other words, this isn't bad news, just a delay. Fully disagree. The world has many implementors eagerly awaiting the arrival of Atom so they can start using it. If there are problems that require repair, I don't want to wait two more weeks to find out about them. This is very disappointing. -Tim
Re: IESG defers discussion of the format document for two weeks
On Jun 23, 2005, at 9:12 AM, Eric Scheid wrote: If there are problems that require repair, I don't want to wait two more weeks to find out about them. This is very disappointing. -Tim we can start with these two... https://datatracker.ietf.org/public/pidtracker.cgi? command=view_commentid= 36536 https://datatracker.ietf.org/public/pidtracker.cgi? command=view_commentid= 36539 Nope, these are non-controversial editorial improvements which need not slow us down, they can go into that last draft that we'd have to do anyhow to fix the errors that have been turned up and put in the contributors and so on. Specifically, they want us to make it clearer that yes, we do have two similar-looking instances of type= with different rules, and to make it clear that to dereference a IRI you have to turn it into a URI. The person who put the defer on didn't raise these issues. -Tim
Re: Signature wording
On Jun 22, 2005, at 11:55 AM, James M Snell wrote: Note that I am not trying to change Atom's model or the core spec, We do agree on Paul's suggested changed saying it's OK to sign entries though, I think. I am trying to define an Atom extension that is capable of meeting a specific problem space that happens to include the types of things aggregators are going to want to be able to do. I think this is a good idea. I'd be pretty strongly against us trying to write some sort of c14n language into the format spec because we have little prior art to draw on with respect to XML DigSig in general, and exactly zero (as far as I know) to draw on for digsig in a feed or aggregated-feed context. So we just totally don't know how this is going to shake down in the market. So I agree. Remove the prohibition on signing entries, and let the engineers figure out what works. -Tim
Re: Signature wording
On Jun 22, 2005, at 12:03 PM, James M Snell wrote: I'm planning to write a separate Internet-Draft that discusses digital signing of Atom feeds and entries. Some parts of that document will includes mandates; other parts will include recommendations. We can describe for entry producers a way of producing signed entries that can be aggregated with original signatures in tact and a set of recommendations to aggregators that wish to pass those signed entries around with signatures in tact. Sure, it's all up to the aggregators and content providers to decide whether or not they want to support those methods -- which is the whole point of I'm working on this as a separate I-D and positioning it as an optional extension to Atom. :-) A man who spots a problem, then volunteers to do the work around fixing it! We need more like that. I suspect that there's an excellent chance that this might become a WG draft, but I remained concerned about our lack of hands-on experience. -Tim
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
On Jun 18, 2005, at 8:00 AM, David Powell wrote: Friday, June 17, 2005, 6:14:38 PM, Tim Bray wrote: My feeling was that we ruled out composite types in *local* content [...] I'm still looking, but my suspicion is that we never did rule them out, and that this restriction crept in during some editorial rephrasing. co-chair-modeI disagree. Atom 0.3 had explicit built-in support for multipart, and there was strong (not rough) consensus support for retiring that and replacing it with the language in the current draft. My recollection of the debate is that it was exclusively focused on the problems of multipart in the document, thus I proposed to the WG that we did not in fact have consensus of banning it in external content; the feedback so far is supportive of the notion that that's a bug in the spec. /co-chair-mode
Re: question about future
On Jun 18, 2005, at 1:15 PM, Domel wrote: How many drafts will you planing to publish to Atom 1.0? That depends on what the IESG says at their meeting of June 23rd. If they say OK there will be a last draft to fix some typos and bugs that people have turned up in -09 and include the final namespace and so on. If they request changes it gets more complicated. -Tim
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
Uh, has Mark spotted a dumb bug here that we should fix? Do we care if *remote* content is of a composite MIME type? My feeling was that we ruled out composite types in *local* content, for fairly obvious reasons. The fix is obvious, in 4.1.3.1 Failing that, it MUST be a MIME media type. If the src attribute is not provided, i.e. the content is local, the value of the type attribute MUST NOT be a composite type... -Tim On Jun 17, 2005, at 7:05 AM, Mark Baker wrote: atom:content type=message/rfc822 src=http://www.example.org/lists/list/archive/12345/ Unfortunately, that's bad Atom. Section 4.1.3.1 of the format spec says; On the atom:content element, the value of the type attribute MAY be one of text, html, or xhtml. Failing that, it MUST be a MIME media type, but MUST NOT be a composite type (see Section 4.2.6 of [MIMEREG]). If the type attribute is not provided, Atom Processors MUST behave as though it were present with a value of text. where composite type is defined to be multipart/* and message/*. If the intent of that restriction was to avoid the whole non-XML attachments issue, then it seems to have failed to account for the use of the src attribute to include the data by reference rather than by value.
Re: Review of Section 6
On Jun 9, 2005, at 9:22 AM, David Powell wrote: Apologies for the rubbish timing, but I've been reviewing section 6, and found a number of problems. Firstly, there are some mismatches between the RelaxNG grammar and the specification text. I know that the RelaxNG grammar isn't normative; but this doesn't mean that it can be contradictory: I've asked Paul, and in fact we can fix typos and outright bugs later on in the process. If you're right about the Relax mismatch (Rob? Norm?) then let's fix that. On the other hand, a general re-organization of section 6 is right out; it is our finding that the format-09 draft (modulo errors) reflects the rough consensus of the WG. If you disagree, the IETF provides appeal procedures. a) Section 6.4 omits atom:source as a valid location for Metadata Extensions, but it is allowed by the RelaxNG in 4.2.11. I believe that the RelaxNG reflects our intent to allow extensions to be preserved in atom:source. Sounds right to me. b) Section 6.4.1 and Section 6.4.2 don't 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 should be reserved for future forwards-compatable revisions of Atom. I find this surprising too, will check further. -Tim
Re: Moving along with protocol work
On Jun 2, 2005, at 10:37 AM, Greg Smith wrote: Can you point to a link describing maybe the process and specifically the structure, format, and submission guidelines for official documents such as a Pace. Don't know of such a link, so here's how it works. Well, go to the wiki (starting at http://www.intertwingly.net/wiki/ pie/AtomPubIssuesList) and read a few Paces to get a feel for it. What I usually do is find a Pace that's suggesting changes similar in flavor to the ones I have in mind, hit Edit this page, copy, the source code, hit cancel, then if I want to create PaceTimsBrainstorm I go and edit http://www.intertwingly.net/wiki/ pie/TimsBrainstorm, the Wiki notices that it doesn't exist, I hit create this page and paste in all the source I copied from the previous page, edit it, and there you go. Exception: if it's a big complicated hairy thing, I take the saved source and paste it into my desktop text editor and fix it up there before I paste it into the new page. If you know some other people on the list who you think might agree with you, contact them have them take a look at the Pace and suggest improvements. Once you've done that, send a message to the list saying I just posted PaceXXX. Some people actually copy the text of the Pace into the email, others just post a link,. Then duck. -Tim
Re: some xmlns:atom tomfoolery
On May 28, 2005, at 2:09 PM, John Panzer wrote: entry titlethe minimal Atom Entry/title summaryA minimal entry has only .../summary content type=application/atom+xml entry ... /entry Or perhaps: feed ... /feed You guys are sick, evil, and twisted. Snicker. -Tim
Re: [Fwd: Re: Signatures - I blog, therefore I am...]
On May 27, 2005, at 11:23 AM, James M Snell wrote: In general, the idea of associating the signing keys with the network resource (feed or entry document URI) makes a lot of sense but I think there may be some issues there with aggregate feeds and intermediaries (e.g. Feedburner) that would need to be worked out. In any case, this is definitely something that should be worked up. If there is interest in coming up with a ID on the topic, I volunteer to help write it up. The question is whether or not this list is the right place to discuss extensions like this or whether we should take this offline? I think that this list is the perfect place to discuss this stuff, the people who care are here. Also, until we get AtomPubIssuesList cleaned up and the format I-D filed, the WG is kind of between tasks, so now is a good time. -Tim
Last and final consensus pronouncement
co-chair-mode On behalf of Paul and myself: This is it. The initial phase of the WG's work in designing the Atompub data format specification is finished over, pining for the fjords, etc. Please everyone reach around and pat yourselves on the back, I think the community will generally view this as a fine piece of work. Stand by for announcements on buckling down on Atom-Protocol. Note that this is a pronouncement, not a call for further debate. Here are the next steps: 1. Editors take the assembled changes and produce a format-09 I-D. Sooner is better. 2. They post the I-D. 3. Paul sends Scott a message, cc'ing the WG, that we're done. 4. At this point there may be objections from the WG. We decide whether to accept the objections and pull the draft back, or tell the objectors they'll have to pursue the appeal process. 5. The IESG process takes over at this point and we'll eventually hear back from them. Last two draft changes: 1. PaceAtomIdDOS We think that the WG has consensus that it is of benefit to add a warning to section 8 Security Considerations. The language from PaceAtomIdDos is mostly OK, except that the late suggestion of talking about spoofing instead of DOS seemed to get general support. I reworded slightly. We'll leave it up to the editors to decide whether a new subsection of section 8 is required. Atom Processors should be aware of the potential for spoofing attacks where the attacker publishes an atom:entry with the atom:id value of an entry from another feed, perhaps with a falsified atom:source element duplicating the atom:id of the other feed. Atom Processors which, for example, suppress display of duplicate entries by displaying only one entry with a particular atom:id value, perhaps by selecting the one with the latest atom:updated value, might also take steps to determine whether the entries originated from the same publisher before considering them to be duplicates. 2. PaceAtom10 http://www.intertwingly.net/wiki/pie/PaceAtom10 We just missed this one in the previous consensus call; seeing lots of +1's and no pushback, it's accepted. /co-chair-mode
Editorship announcement
co-chair-mode As we get ready to buckle down on the Atom Publishing Protocol draft, we're doing some editor-shuffling. With thanks to Rob Sayre for his excellent work up through protocol-04, we're shifting from Rob-and- Joe to Joe Gregorio and Bill de hÓra as co-editors of the Atom protocol draft. -Tim (on behalf of myself and Paul) /co-chair-mode
Consensus snapshot, 2005/05/25
The level of traffic in recent days have been ferocious, and reading through it, we observe the WG has consensus on changing the format draft in a surprisingly small number of areas. Here they are: 1. The restriction that atom:author can appear only once is removed. 2. The draft should include an explanation that if entry/author is absent, then all entry/source/author entries apply if there are any, otherwise all feed/author entries apply. 3. Change to previous consensus call. The phrase that begins If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they describe the same empty... loses the language about how software MUST treat them as such. 4. atom:id is a compulsory child of atom:feed (or did we already say that?) 5. rework the last paragraph of 4.1.3.2. First of all, the description involving text/ and +xml needs fixing per Thomas Broyer's work (see http://www.imc.org/atom-syntax/mail-archive/ msg15444.html), and second, the SHOULD is gone, see http:// www.imc.org/atom-syntax/mail-archive/msg15412.html Have I missed any? Yes, there has been high-volume debate on several other issues; but have there been any other outcomes where we can reasonably claim consensus exists? -Tim
Re: extension elements inside link elements?
On May 25, 2005, at 1:40 PM, David Powell wrote: What is section 6.3 unknown foreign markup for? I think the notion of foreign markup exists so that we can write the extremely-important section 6.3, our MustIgnore assertion. The point is, either software knows what to do with an extension and does it, or if not it's not allowed to to break and should pass text through in contentful contexts. -Tim * We have content constructs which are extensible by allowing any type of data to be embedded using the IANA registry of MIME types. * We have carefully designed an IANA registry for @rel values, and used the distributed nature of namespace URIs to allow for unregistered values. * We have carefully defined two classes of extension construct (Simple and Structured) to ensure that extensions are disambiguated by namespace URIs, and that xml:lang issues are considered. Simple extensions make generic support for this class of extension feasible for real-world implementations; Structured extensions are there for those that need the extra power. And, we have unknown foreign markup. I believed that the purpose of unknown foreign markup was to define an error handling strategy for parsers, and to give the spec a bit of breathing room for things like Atom 1.1. This is great. But I'm getting a sneaking suspicion though, that unknown foreign markup is positioning itself as a third (poorly thought through) class of extension point. Please tell me that that isn't the intent? In the future someone said: Hey, I've had an idea for an extension to atom:link. The text content of atom:link could be a tooltip giving a long description for the link It would work like this: atom:link rel=alternate href=http://example.com/dave; This is a picture of my holiday. I'm the one on the right. /atom:link What do you think? In the future someone said: Hey, I've had an idea for an extension to atom:link. The text content of atom:link could be a GUID of an ActiveX control that is capable of displaying the linked object. It would work like this: atom:link rel=alternate href=http://example.com/dave; 0A28AB31-3143-4b70-B969-8650BDFDBAC9 /atom:link What do you think? -- Dave
Re: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25)
On May 25, 2005, at 1:49 PM, Graham wrote: Atom Processors should be aware of the potential for denial of service attacks where the attacker publishes an atom:entry with the atom:id value of an entry from another feed, and perhaps with a falsified atom:source element duplicating the atom:id of the other feed. Atom Processors which, for example, suppress display of duplicate entries by displaying only one entry with a particular atom:id value or combination of atom:id and atom:updated values, might also take steps to determine whether the entries originated from the same publisher before considering them to be duplicates. How is this a Denial of service attack? Isn't it just ordinary spoofing/impersonation? Apart from that, +1. Yeah, it seems like it can't possibly be wrong to highlight this risk, which I at least didn't notice until someone pointed it out to me, so I bet others will miss it too. -Tim
Re: atom:type, xsl:output
On May 24, 2005, at 1:25 AM, Graham wrote: First off: it is an error to lie about your media-type, so I would change SHOULD be suitable for handling as the indicated media type to MUST be suitable for handling as the indicated media type. +1 I'm tempted to agree but can't, because the condition of being suitable for handling as is not deterministic and testable enough to merit a MUST. -Tim
Re: extension elements inside link elements?
On May 24, 2005, at 10:43 AM, Graham wrote: I also think removing that piece of text makes it unclear that the element is normally empty. +1 -Tim
Author and contributor
co-chair-modeWe observe a significant amount of discomfort with the current one-author/multiple-contributors model in atom-format. Despite the mentions that Rob dug up, nobody can claim this has had serious in-depth discussion in the IETF context. On the other hand, we note that the current setup does have a coherent logical grounding, namely adopting Dublin Core semantics by identifying a singular primary-creator role and a plural contributor role. If we leave things the way they are, a pointer to this derivation would improve the draft. However, aside from Rob Sayre, nobody has been particularly militant in defending the current setup. Personally I don't think any of the alternatives proposed are going to have fewer corner cases, but quite likely they won't have more either. Unfortunately, among those who want to change the current setup, we do not observe consensus on the subject of what to change them to. Near as we can tell, people want to make atom:author plural, some want to nuke atom:contributor and others don't. If, in the next couple of days, a large number of people can coalesce behind ONE SPECIFIC change to the spec in this area, and there is no significant body of resistance to this change, Paul and I are prepared to be convinced that rough consensus exists for such a change./co-chair-mode
Re: atom:type, xsl:output
On May 23, 2005, at 2:43 AM, Graham wrote: * When @type=html then the content of the element is a xsd:string [1] of an HTML DIV element plus optional insignificant whitespace around it. Which version of HTML is defined? How do you differentiate between HTML 4.01, HTML 3.2, the upcoming HTML 5, or nonstandard HTML (like with marquee elements)? I believe the answer would be street HTML, not any specific version. Agreed. What it says is SHOULD be suitable for handling as HTML. I.e. can be passed to your local HTML rendering control, which is doubtless a forgiving tag-soup engine. -Tim
Re: PaceClarifyAuthorContributor posted
On May 23, 2005, at 5:18 AM, Graham wrote: On 23 May 2005, at 1:09 pm, Robert Sayre wrote: Fully disagree. Try a record album by the Rolling Stones or Grandmaster Flash and The Furious 5. OK to list the band members as contributors? Definitely. Maybe there's a minor bug in the wording here Uh, Graham, I thought your Pace did a good job of capturing the consensus that seems to be emerging, and then slipped in just a little extra with the name-duplication rules. I'm with Rob, that stuff is past the 80/20 point, I'd suggest you pare down the Pace as a friendly amendment. -Tim
Re: PaceClarifyAuthorContributor posted
On May 23, 2005, at 7:45 AM, James Aylett wrote: Baking it into the spec strikes me as needlessly creating rules - we can be precise about what the semantics are without this rule, IMHO. +1 -Tim
