The probably-last gang of issues
Greetings again. Sam's recent work queue rotation marks what we consider to be the likely final rotation before we are finished with the Atom format draft. That is, the goal is that, once we accept or close all of the items from the rotation, the format document editors will have a complete picture of what the WG wants in the Atom format spec. (For those of you new to this process, the full list of currently under discussion is at http://www.intertwingly.net/wiki/pie/AtomPubIssuesList.) This ties in nicely with our goal of turning the format spec in for IETF Last Call before March. Of course, changes can (and probably will) be made based on the input to the WG from the IETF Last call. Those changes can come from the IETF community as a whole or from the WG as we stare one more time at the document (and as the implementers write code to it). However, there is a goal of not needing to revise the document after IETF Last Call; that is, we don't send the document to the IETF for review if we know that there are topics on which there is WG consensus that is not reflected in the document. So, please take a look at all of the Paces listed as currently under discussion and comment freely. We're getting close to being finished, which is of course the over-arching goal. --Paul Hoffman, Director --Internet Mail Consortium
Stand by for a flurry of Pace overviews
Sam has updated our Public Issues List, and Paul has talked about about where we'd like to get to. I'm about to send fifteen separate messages, one for each of the 15 (!) format-related Paces up for their (hopefully) last go-around. These are the result of discussion between Paul and Sam and myself, and represent our take on what our consensus call would be if there were no further discussion. They may also prove to be convenient anchors for per-Pace discussion threads. -Tim
PaceExtensionConstruct status
If there were no further discussion: This has received no -1s, but also not a lot of wild enthusiasm. Support at the moment is a bit marginal, but some +1s from implementors would probably make it a slam-dunk. -Tim
PaceEntriesAllTheWayDown status
If there were no further discussion: This is a radical change to the document and, so far, hasn't gathered widespread enough support to make it over the line. -Tim
PaceDateofSubject status
If there were no further discussion: This topic was beaten to death a few times in the WG. Unless there is a wave of enthusiasm unaccompanied by -1s, the dates in the current Internet Draft will be all that ships with the final document. -Tim
PaceExtendingAtom status
If there were no further discussion: This is the result of a lot of discussion around Must Ignore and has in various drafts received lots of friendly remarks and suggestions for improvement, which have been incorporated. Absent some convincing -1s, it probably goes in. -Tim
Re: PaceDateUpdated2 status
Tim Bray wrote: If there were no further discussion: This topic was beaten to death a few times in the WG. Unless there is a wave of enthusiasm unaccompanied by -1s, the dates in the current Internet Draft will be all that ships with the final document. -Tim +1. I think this really is a consensus. FYI: http://www.itst.org/web/308-atom_04.shtml
Re: PaceSyntaxGuidelines status
It reads like more of a guideline than a Pace. Inspecting the format for conformance to these guidelines and generating Paces for non-conformances seems like a better way to proceed than to actually add this text to the spec. -joe On Mon, 24 Jan 2005 16:17:36 -0800, Tim Bray [EMAIL PROTECTED] wrote: If there were no further discussion: Hasn't got enough support so far, but also has had no opposition we can find. -Tim -- Joe Gregoriohttp://bitworking.org
Re: PaceDateofSubject status
Tim Bray wrote: If there were no further discussion: This topic was beaten to death a few times in the WG. Unless there is a wave of enthusiasm unaccompanied by -1s, the dates in the current Internet Draft will be all that ships with the final document. That is, PaceDateOfSubject won't go in? +1 to that. Funny enough, I am listed as one of the supporters of this pace. In fact, I am not: http://www.imc.org/atom-syntax/mail-archive/msg07767.html
Re: PaceSyntaxGuidelines status
On Jan 24, 2005, at 5:02 PM, Joe Gregorio wrote: It reads like more of a guideline than a Pace. Inspecting the format for conformance to these guidelines and generating Paces for non-conformances seems like a better way to proceed than to actually add this text to the spec. Actually, take a closer look, I got fooled too it first glance: It's talking about how *extensions* should use syntax, not how the spec should. -Tim
Re: PaceMustBeWellFormed status
It's good work but it belongs in a primer or best practices document. -joe On Mon, 24 Jan 2005 16:17:40 -0800, Tim Bray [EMAIL PROTECTED] wrote: If there were no further discussion: The WG completely failed to converge to consensus on these issues last time around. Consensus can still be found here. -Tim -- Joe Gregoriohttp://bitworking.org
Re: PaceFeedLink status
+1 The alternative is that blasted feed:// URI type... -joe On Mon, 24 Jan 2005 16:17:44 -0800, Tim Bray [EMAIL PROTECTED] wrote: Not yet taken up by the WG, depends on the discussion that comes with this call. Same rules as all the others: there has to be a positive WG consensus that each adds to the base specification. -Tim -- Joe Gregoriohttp://bitworking.org
Re: PacePersonLinks status
-1 If I understand all the Paces correctly, couldn't you get the same effect by including foaf as a Structured Extension of Person? -joe On Mon, 24 Jan 2005 16:17:39 -0800, Tim Bray [EMAIL PROTECTED] wrote: If there were no further discussion: Has failed to get anywhere near enough support to call rough consensus in previous go-arounds. -Tim -- Joe Gregoriohttp://bitworking.org
Re: PaceEnclosuresAndPix status
+1 Should there be a suggested size for images? -joe On Mon, 24 Jan 2005 16:18:00 -0800, Tim Bray [EMAIL PROTECTED] wrote: If there were no further discussion: Got no -1's, seems useful, needed for feature parity with RSS2, will likely go in absent some objections. -Tim -- Joe Gregoriohttp://bitworking.org
Re: PaceExtendingAtom status
+1 for making Atom a 'Must Ignore' language. On Mon, 24 Jan 2005 16:17:46 -0800, Tim Bray [EMAIL PROTECTED] wrote: If there were no further discussion: This is the result of a lot of discussion around Must Ignore and has in various drafts received lots of friendly remarks and suggestions for improvement, which have been incorporated. Absent some convincing -1s, it probably goes in. -Tim -- Joe Gregoriohttp://bitworking.org
Re: PaceMustBeWellFormed status
On Jan 24, 2005, at 5:12 PM, Joe Gregorio wrote: It's good work but it belongs in a primer or best practices document. +1. I like it, I'd like to use it somewhere, but I don't think it belongs in the core spec. -Tim
Re: PaceEnclosuresAndPix status
On Jan 24, 2005, at 5:18 PM, Joe Gregorio wrote: +1 Should there be a suggested size for images? A suggested aspect ratio, actually. Drat. Brent Simmons loved this idea, and I meant to update the draft. Would anyone be upset if I updated the draft to say an aspect ratio of 2 (horizontal) to 1 (vertical)? -Tim
Re: PaceSyntaxGuidelines status
On Mon, 24 Jan 2005 17:08:45 -0800, Tim Bray [EMAIL PROTECTED] wrote: On Jan 24, 2005, at 5:02 PM, Joe Gregorio wrote: It reads like more of a guideline than a Pace. Inspecting the format for conformance to these guidelines and generating Paces for non-conformances seems like a better way to proceed than to actually add this text to the spec. Actually, take a closer look, I got fooled too it first glance: It's talking about how *extensions* should use syntax, not how the spec should. -Tim In that case +1. -joe -- Joe Gregoriohttp://bitworking.org
Re: PaceDateUpdated2 status
On 25 Jan 2005, at 12:17 am, Tim Bray wrote: If there were no further discussion: This topic was beaten to death a few times in the WG. Unless there is a wave of enthusiasm unaccompanied by -1s, the dates in the current Internet Draft will be all that ships with the final document. -Tim The language in the current draft is much cleaner, and I'd like to keep that. Since not much of this Pace is compatible with that language, the Pace itself is a -1. BUT, making the updated date optional is something I support. Anyone else? Graham smime.p7s Description: S/MIME cryptographic signature
Re: PaceAttributesNamespace status
On 25 Jan 2005, at 12:17 am, Tim Bray wrote: Not yet taken up by the WG, depends on the discussion that comes with this call. Same rules as all the others: there has to be a positive WG consensus that it adds to the base specification. -Tim -1 Unacceptable. Language is too broad and is meaningless outside the RDF context, which is where it should stay. Graham smime.p7s Description: S/MIME cryptographic signature
Re: PaceEntryDeletion status
-1 This approaches the problem from the wrong end. A better way to solve it would be to list entries that weren't deleted, but expired. A more complex solution would be to HEAD the link (or id or something) and see if you get a 404. Graham On 25 Jan 2005, at 12:17 am, Tim Bray wrote: If there were no further discussion: The earlier discussion for this was inconclusive. The demand doesn't seem high enough to get it over the goal line, but if there is a wave of enthusiasm, there didn't seem to be that much opposition. -Tim smime.p7s Description: S/MIME cryptographic signature
Re: PaceExtensionConstruct status
Joe Gregorio wrote: +1 to the general Pace, but I would prefer to see the 'Simple Extension' dropped. It adds a level of complexity that isn't requried. and for no discernable benefit. For example, the Pace states that A Simple Extension construct MUST NOT have any attributes or child elements. Does that mean that a Simple Extension can't use xml:lang? Does a formerly Simple Extension become a Structured Extension if it requires internationalization? I work best with specific example. How should wfw:comment be handled? - Sam Ruby
Re: PaceExtensionConstruct status
On Mon, 24 Jan 2005 20:41:40 -0500, Sam Ruby [EMAIL PROTECTED] wrote: Joe Gregorio wrote: +1 to the general Pace, but I would prefer to see the 'Simple Extension' dropped. It adds a level of complexity that isn't requried. and for no discernable benefit. For example, the Pace states that A Simple Extension construct MUST NOT have any attributes or child elements. Does that mean that a Simple Extension can't use xml:lang? Does a formerly Simple Extension become a Structured Extension if it requires internationalization? I work best with specific example. How should wfw:comment be handled? As a Structured Extension. Is there a benefit to being a 'Simple Extension' that I am missing? -joe -- Joe Gregoriohttp://bitworking.org
Re: PaceEntriesAllTheWayDown status
On 25 Jan 2005, at 12:17 am, Tim Bray wrote: If there were no further discussion: This is a radical change to the document and, so far, hasn't gathered widespread enough support to make it over the line. -Tim -1 Architectural astronautics at its most textbook. Graham smime.p7s Description: S/MIME cryptographic signature
Re: The probably-last gang of issues
2 questions: 1. Is there a deadline for new feature proposals? Has it passed? There's one I want to make that depends on whether or not one in the current round is accepted. 2. The Pace process doesn't encourage proposing minor (editorial, style, etc) changes. It also seems to have encouraged proposals that are good in principle but poorly worded to be incorporated. Will there be a period of time for nitpicking and copyediting? Graham smime.p7s Description: S/MIME cryptographic signature
Re: PaceExtensionConstruct status
* Joe Gregorio [EMAIL PROTECTED] [2005-01-24 20:44-0500] On Mon, 24 Jan 2005 20:41:40 -0500, Sam Ruby [EMAIL PROTECTED] wrote: Joe Gregorio wrote: +1 to the general Pace, but I would prefer to see the 'Simple Extension' dropped. It adds a level of complexity that isn't requried. and for no discernable benefit. For example, the Pace states that A Simple Extension construct MUST NOT have any attributes or child elements. Does that mean that a Simple Extension can't use xml:lang? Does a formerly Simple Extension become a Structured Extension if it requires internationalization? I work best with specific example. How should wfw:comment be handled? As a Structured Extension. Is there a benefit to being a 'Simple Extension' that I am missing? Is it that they're unconstrained enough that one might hope to generate a UI for any simple extension without knowing much about the particular properties being used? Answering a question with a question, Dan
Re: The probably-last gang of issues
On Jan 24, 2005, at 5:45 PM, Graham wrote: 1. Is there a deadline for new feature proposals? Has it passed? There's one I want to make that depends on whether or not one in the current round is accepted. This being an IETF WG, you can always post a comment to a draft. If rough consensus occurs, in it goes. The current flurry is about achieving closure on a bunch of known issues, and about our belief that the Atom data format is getting nicely cooked; but the door isn't closed until the IESG says done. 2. The Pace process doesn't encourage proposing minor (editorial, style, etc) changes. It also seems to have encouraged proposals that are good in principle but poorly worded to be incorporated. Will there be a period of time for nitpicking and copyediting? I think it's be just fine to have editorial and style and language debates right here on the WG any old time. It might be nice to put [Editorial] or some such in the subject line. -Tim
Re: PaceDateUpdated2 status
On 25/1/05 12:33 PM, Graham [EMAIL PROTECTED] wrote: BUT, making the updated date optional is something I support. Anyone else? I originally thought so, but was willing to bend to the will of the developers that didn't like having an element that may or may not be there and thus required some manner of implied value or some such so sorting etc would work in some predictable manner. In a world where date-updated is optional, is it implied that an entry with no date-updated has a last significant change date being the date-published? I'd like it to be optional. If optional, then it's easy to leave out for those publishing systems that don't facilitate a method for subjectively marking an modification/edition/change as being significant, and by not being required to be filled with something would thus not appear to so tempting a target for date of last modification, no matter how trivial or banal. Did someone do a survey of what date concepts the various blog publishing systems support? e.
Re: PaceFeedLink status
On 25/1/05 11:17 AM, Tim Bray [EMAIL PROTECTED] wrote: Not yet taken up by the WG, depends on the discussion that comes with this call. Same rules as all the others: there has to be a positive WG consensus that each adds to the base specification. -Tim +1 for this pace - the tangible benefits to aggregators outweigh the unlikely negatives of a publisher spoofing some other feed's URI. e.
Re: PaceSyntaxGuidelines status
Joe Gregorio wrote: On Mon, 24 Jan 2005 17:08:45 -0800, Tim Bray [EMAIL PROTECTED] wrote: On Jan 24, 2005, at 5:02 PM, Joe Gregorio wrote: It reads like more of a guideline than a Pace. Inspecting the format for conformance to these guidelines and generating Paces for non-conformances seems like a better way to proceed than to actually add this text to the spec. Actually, take a closer look, I got fooled too it first glance: It's talking about how *extensions* should use syntax, not how the spec should. -Tim In that case +1. -1. Adds no value. Most people will look at the spec without reading it, imitate the examples, and end up with similar syntax anyway. People who take the time to read the spec are even less likely to do something ugly. That mostly leaves elements from existing vocabularies. Robert Sayre
Re: PaceSyntaxGuidelines status
7.2 Common element usage The following actual elements should only be used in the ways specified below. * link: Purposes of link elements are specified by a list of legal values for link/@rel, and we are considering allowing extensions to specify additional values. If the external resource being referred to is not one that would make sense to present to the user as a clickable link, some other element should be used instead. For example, link is used to point to an alternate representation of the content of the entry, to the next set of entries in a feed, etc. The link element is not appropriate for pointing to things like a stylesheet for the feed, an XSL template, etc., which are not intended for viewing by the user. Although I'm in favor of this concept, the workgroup has rejected efforts to incorporate such language into the definition of link constructs. Are we going to recommend this for extensions if we're not going to hold the core to it? If so, this section needs rewording.
Re: AtomAsRDF_PaceAttributesNS
At 06:38 05/01/25, Sam Ruby wrote: Henry Story wrote: We are all working together on the proposal, in an iterative fashion. This is very similar to the way one develops software projects in Agile or Extreme programming methodology. First one starts with a prototype. One gets the major pieces in place, and gets general feedback from the clients. One checks that it works. Then one iteratively works towards a goal of getting something that satisfies the clients needs and budget. But you are correct to demand some real code. I have branched off the particular topic in AtomAsRDF_PaceAttributesNS [1], so that those that only want to work on detailed text, can get going debating and refining that. I would be very thankful if someone with more specification experience could get it into the correct final format. It is not code that Tim is asking for, but merely words. The specification is but a set of paragraphs, and somebody needs to say insert these words there. As to the words that you have proposed, I have a technical question: if you are equating unnamed attributes with attributes in the atom namespace, then everybody who looks today for an href attribute would *also* have to look for an atom:href attribute. Multiply this by all of the attributes defined in the specification, and IMHO, you have a solution that is *worse* than requiring the atom namespace in the first place. So, -1 That's not the way I have understood this. What I thought this to be is: In Atom, these attributes always are unprefixed. They are in the Atom namespace just for the purposes of RDF. From my perspective, Atom can be one XSLT translation away from RDF/XML, and will likely remain such. We can capture that translation as a non-normative appendix to the spec. We can also look at GRDDL or other techniques for making this explicit in the documents. But what I don't want is to make the syntax dramatially worse for people who want to use simple XML processing tools. Agreed. I just saw the text that we would insert into the spec as a verbal description of one aspect (adding an Atom-namespace prefix) of that transformation. But I can see that the current text, Processors should interpret unprefixed attributes in atom namespaced elements to be in the atom namespace, can easily be interpreted the way you have done it. I think this can be fixed by changing it to something like For the purpose of transformation to or interpretation as RDF, unprefixed attributes in atom namespaced elements to be interpreted as being in the atom namespace. I guess that Henry didn't add the clarification because he saw the text in the context of an overall AtomAsRDF section, which would make the context clear enough. Regards,Martin.
Re: PaceExtensionConstruct status
David Powell wrote: (I couldn't find a list of RSS2.0 extensions). http://blogs.law.harvard.edu/tech/directory/5/specifications/rss20ModulesNamespaces - Sam Ruby
Re: PaceFeedState status
On Monday, January 24, 2005, at 06:09 PM, Joe Gregorio wrote: I am +1 on the //atom:head/atom:[EMAIL PROTECTED]'prev'], but -1 on //atom:head/atom:[EMAIL PROTECTED]'wholefeed'] and -1 on any of the verbage that makes demands on clients, for example, Atom consumers MUST warn users when they do not have the complete state of a feed Agreed, agreed and agreed. When a new Atom Feed Document is received by a consumer, the entries in it are compared to those that are already known to belong to the same Atom Feed, in reverse document order (that is, starting with the last entry in the Atom Feed Document and working towards the first). If an entry from the document has the same 'id' attribute as an existing entry, the metadata associated with it replaces that currently associated with the entry completely. Any existing metadata, whether or not present in the new entry, is removed. I think this is beyond the scope of the specification. First, the reverse document order part is unnecessary and inappropriate. Second, the client may keep the history of an entry--we shouldn't be mandating that the old metadata be discarded. By following such links progressively backwards and incorporating the changes in each associated Atom Link document, until it encounters a link to a document it already has seen (as identified by the //atom:head/atom:[EMAIL PROTECTED]'this'] element), a consumer can reconstruct the state of a feed reliably. I'm not sure I'm in favor of this method. If, for example, the sliding window into one's feed contains 15 entries, and the prev link points to the prior 15 entries, unless one polls when a multiple of 15 entries have been added, you'll never see the same batch of entries you saw last time. Of course, feeds could be implemented in a way that avoided this problem...and I'm not sure I can think of a better method off hand. If for example you were to keep going backward till one saw an entry/id they'd seen before, you might stop too early if an entry had been altered and moved nearer the top of the feed. If you were to try to avoid this mistake by checking entry/updated for a change, you could still fail if the publisher decided not to bump its value (I for one would not change the order of entries without changing updated, but that's not to say others won't).
Re: The probably-last gang of issues
Paul Hoffman wrote: At 1:45 AM + 1/25/05, Graham wrote: 2. The Pace process doesn't encourage proposing minor (editorial, style, etc) changes. Fully agree. -05 is almost done right now. All valid -04 documents are valid -05 documents. Many editorial suggestions have been incorporated. I suspect Graham will prefer it. We can pick up the pace to incorporate wording and nitpick changes. Robert Sayre
Re: PacePersonLinks status
On Monday, January 24, 2005, at 06:25 PM, Eric Scheid wrote: On 25/1/05 11:17 AM, Tim Bray [EMAIL PROTECTED] wrote: If there were no further discussion: Has failed to get anywhere near enough support to call rough consensus in previous go-arounds. -Tim was that failure of consensus due to pushback on the very concept of link itself (or related @rel disharmony), or actual disagreement with the use of link in person? I'm in favor of the basic concept. I'm a little afraid of the list of proposed @rel values it would spawn--that people would want to be able to specifically point to too many things that are very similar to each other. I don't expect the proposal to achieve consensus. Looks like a good opportunity to float an extension and see if it gets widely adopted.
Re: PaceEnclosuresAndPix status
On Monday, January 24, 2005, at 05:18 PM, Tim Bray wrote: If there were no further discussion: Got no -1's, seems useful, needed for feature parity with RSS2, will likely go in absent some objections. -Tim -0.7. Turns link into a kitchen sink by using it to point to things that are intended to be pre-fetched and presented along with the content (image, at least, though perhaps not enclosure). But given that we've failed to achieve consensus on any language to limit the range of uses of link, perhaps that argument is dead.
Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS)
* Danny Ayers wrote:
To be inserted:
{{{
Section 2. Atom Documents
Atom processors MAY interpret unprefixed attribute names as their
namespace-qualified equivalents.
If they do, then all Atom attribute names MUST appear in the Atom namespace.
}}}
This does not make much sense to me, it is either not possible to write
a test case for the first requirement in which case this would be an im-
plementation detail which is out of scope of the specification, or it is
possible to write such a test case in which case this would render Atom
inconsistent with a broad range of XML technologies, e.g., for
atom:foo bar=baz /
an XPath expression
*[namespace-uri() = $x)]/@*[namespace-uri() = $x]
where $x is the Atom namespace URI would be allowed to match. I am -1 on
any proposal that allows or requires to put Atom-defined attributes on
Atom elements in any namespace or process Atom documents as if they were
constructed like that if you can tell the difference.
--
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: PaceSimpleLanguageTagging status
* Martin Duerst wrote: Not yet taken up by the WG, depends on the discussion that comes with this call. Same rules as all the others: there has to be a positive WG consensus that each adds to the base specification. -Tim +1, at least for atom:language inside the header. For elements, well, there _are_ use cases for elements in different languages, so, since it is optional, +1 again. -1, or better, -2. Inventing things like atom:language when there is xml:lang is just completely useless and superfluous. Could you clarify how xml:lang solves the problems stated in the Pace? The alternatives to the Pace would seem to be either restrict xml:lang to specific elements or implementations that lose xml:lang information or, in an authoring scenario, do not allow to use it -- i.e., ignoring the problem in the specification. Neither of which is really helped by xml:lang, so your comment seems a bit weird. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
