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 elemen

Re: PaceSimpleLanguageTagging status

At 10:00 05/01/25, Sascha Carlin wrote: > >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 each adds to the base specification. -Tim > >+1, at least for atom:language in

Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS)

* Sam Ruby wrote: >I'm a bit concerned about precedence rules (what happens if there is an >href attribute *AND* an atom:href attribute?). What makes most sense >here is for a prohibition disallowing such in any exension. I would >support such a rule. Allowing either atom:href or href is not

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,

Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS)

* Antone Roundy wrote: >BTW, am I remembering correctly that "xml:" in "xml:lang" and >"xml:base" isn't a namespace prefix? You don't see xmlns:xml="..."--so >is "xml:" not a namespace prefix, or does it just not have to be >declared? If it IS a namespace prefix, then the above language works

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 into a kitchen sink by using it to point to things that are intended to b

Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS)

Antone Roundy wrote: BTW, am I remembering correctly that "xml:" in "xml:lang" and "xml:base" isn't a namespace prefix? You don't see xmlns:xml="..."--so is "xml:" not a namespace prefix, or does it just not have to be declared? If it IS a namespace prefix, then the above language works only if

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 pus

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 susp

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

Re: PaceExtensionConstruct status

On 25/1/05 1:10 PM, "David Powell" <[EMAIL PROTECTED]> wrote: > The benefit is that it allows a number of existing vocabularies to be > used with Atom, without them needing rewriting for Atom. example please e.

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: 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 ma

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

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

Re: PacePersonLinks status

On 25/1/05 12:16 PM, "Joe Gregorio" <[EMAIL PROTECTED]> wrote: > If I understand all the Paces correctly, couldn't you get the same > effect by including foaf as a Structured Extension of Person? only by including the foaf XML right there in the feed (oh the bloat!), or at least sufficient of th

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

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

Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS)

Danny Ayers wrote: One thing I'm not sure about - where it currently says "Atom processors", perhaps that would be better as merely "Atom consumers". For the reasons Sam gave, we don't really want extra variability in what's being produced, but this still would still allow RDF-like consumers to int

Re: The probably-last gang of issues

At 2:19 AM + 1/25/05, Graham wrote: (though I will be listing examples willy and indeed nilly once the next draft is published) Feel free to start listing them now. Waiting is OK too, but wording fixes suggested now will make the last steps even easier. --Paul Hoffman, Director --Internet Ma

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,

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

Re: PaceSyntaxGuidelines status

On 25 Jan 2005, at 12:17 am, Tim Bray wrote: If there were no further discussion: Hasn't got enough support so far, but also has had no opposition we can find. -Tim -1 I don't think it's useful or necessary. It's also a bit chatty. Graham smime.p7s Description: S/MIME cryptographic signature

Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS)

On Monday, January 24, 2005, at 04:42 PM, Danny Ayers wrote: On Mon, 24 Jan 2005 14:52:52 -0700, Antone Roundy <[EMAIL PROTECTED]> wrote: On Monday, January 24, 2005, at 02:03 PM, Danny Ayers wrote: Atom processors MAY interpret unprefixed attribute names as their namespace-qualified equivalents

Re: PaceAttributesNamespace status

You can xslt convert anything to anything. That is not very helpful for defining an extensibility framework. Extensibility and a model are requirements for this working group. So these are central concerns. If you have an xslt based extensibiliy solution then please describe it in your own Pac

Re: The probably-last gang of issues

On 25 Jan 2005, at 2:08 am, Paul Hoffman wrote: At 1:45 AM + 1/25/05, Graham wrote: 1. Is there a deadline for new feature proposals? Has it passed? It has passed. We have been talking about finishing for quite a while, and our March milestone is coming up quickly. That sounds like you making

Re: PaceDateofSubject status

On 25/1/05 12:08 PM, "Sascha Carlin" <[EMAIL PROTECTED]> wrote: > Funny enough, I am listed as one of the supporters of this pace. In fact, I am > not: That message of yours talks about "dateline", a similar concept but one which was di

Re: AtomPubIssuesList for 2005/01/24

On Jan 24, 2005, at 5:52 PM, Paul Hoffman wrote: At 5:03 PM -0800 1/24/05, Roy T. Fielding wrote: Why don't you just invent a status of "incomplete" and leave them off the table until completed? It doesn't make sense to close issues that are not resolved one way or another. It does make sense this

Re: The probably-last gang of issues

At 1:45 AM + 1/25/05, Graham wrote: 1. Is there a deadline for new feature proposals? Has it passed? It has passed. We have been talking about finishing for quite a while, and our March milestone is coming up quickly. There's one I want to make that depends on whether or not one in the curr

Re: PaceExtensionConstruct status

Tuesday, January 25, 2005, 12:59:21 AM, you 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. It adds a few lines to the spec, but they are only relevant to extension

Re: PaceSyntaxGuidelines status

On Jan 24, 2005, at 4:17 PM, Tim Bray wrote: If there were no further discussion: Hasn't got enough support so far, but also has had no opposition we can find. -Tim You know, I'd never really thought about this one, but now that I have, I wonder why on earth we should be trying to micromanage s

Re: PaceAttributesNamespace status

On Tue, 25 Jan 2005 02:57:42 +0100, Henry Story <[EMAIL PROTECTED]> wrote: > The point is to allow a very clear structure for Atom extensibility to > be defined, as > specified by the Atom working group charter. See AtomAsRDF and AtomOWL. > The point > of the exercise is to make this as invisible

Re: AtomAsRDF_PaceAttributesNS

On 24 Jan 2005, at 22:38, 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 pi

Re: PaceEnclosuresAndPix status

On 25 Jan 2005, at 1:18 am, Joe Gregorio wrote: Should there be a suggested size for images? Yes. -1 on images section if suggested sizes aren't added. I think favicons are more commonly displayed than logo images, so a link type or at least suggested size for them would be welcome. Graham smim

Re: PaceDateUpdated2 status

On 25/1/05 11:17 AM, "Tim Bray" <[EMAIL PROTECTED]> 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 do

Re: AtomPubIssuesList for 2005/01/24

At 5:03 PM -0800 1/24/05, Roy T. Fielding wrote: Why don't you just invent a status of "incomplete" and leave them off the table until completed? It doesn't make sense to close issues that are not resolved one way or another. It does make sense this late in the process. As we said on the list, af

Re: PaceMustBeWellFormed status

On 25 Jan 2005, at 12:17 am, Tim Bray 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 -1 Phrases like "must be parsed with" seem to be dictating implementation rather than int

Re: PaceAttributesNamespace status

The point is to allow a very clear structure for Atom extensibility to be defined, as specified by the Atom working group charter. See AtomAsRDF and AtomOWL. The point of the exercise is to make this as invisible as possible to anyone other than those who need to write extensions. The intention

Re: PaceExtensionConstruct status

Joe Gregorio wrote: 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

Re: PaceFeedLink status

* Joe Gregorio <[EMAIL PROTECTED]> [2005-01-24 20:13-0500] > > +1 The alternative is that blasted feed:// URI type... Yup, +1 from me too Dan

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 p

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/

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 P

Re: Revisiting feed discovery

On 20/1/05 3:46 AM, "Arve Bersvendsen" <[EMAIL PROTECTED]> wrote: >>> a) Change rel="alternate" to rel="feed", rel="subscription" or similar. >> >> On one (technical) level both make sense. However given that the >> current version is pretty widely deployed, a) at least could be >> counter-produ

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."

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 w

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 meaningle

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 lang

Re: PacePersonLinks status

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 itself (or related @rel d

Re: PaceEntryDeletion status

On 25/1/05 11:17 AM, "Tim Bray" <[EMAIL PROTECTED]> 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 oppos

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

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

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: PaceAttributesNamespace status

-1 Ick. The only example given of a case where this may cause others problems is RDF, and I thought we were going to have a non-normative Atom -> RDF XSLT? Are there other cases I am unaware of? -joe On Mon, 24 Jan 2005 16:17:53 -0800, Tim Bray <[EMAIL PROTECTED]> wrote: > > Not yet taken

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 sugges

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 > >

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

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

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 >

Re: PaceFeedState status

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 " -joe On Mon, 24 Jan

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

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

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 PROTECT

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 consens

Re: AtomPubIssuesList for 2005/01/24

On Jan 24, 2005, at 3:18 PM, Sam Ruby wrote: I'm recommending AtomAsRDF and PaceFeedRecursive for closure merely because they are incomplete. If they become complete, I will update their status accordingly. Note: I already have scheduled PaceAttributesNamespace which is a progeny of AtomAsRDF.

Re: PaceSimpleLanguageTagging status

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 each adds to the base specification. -Tim +1, at least for atom:language inside the header. For elements, well, there _are_

Re: PaceExtensionConstruct status

+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 t

Re: PaceEntryDeletion status

-1 Too much of an edge case with no discenable benefit. On Mon, 24 Jan 2005 16:17:46 -0800, Tim Bray <[EMAIL PROTECTED]> 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

PaceAttributesNamespace status

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

PaceDateUpdated2 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

PaceSyntaxGuidelines status

If there were no further discussion: Hasn't got enough support so far, but also has had no opposition we can find. -Tim

PaceEnclosuresAndPix status

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

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

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

PaceMustBeWellFormed status

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

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

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

PaceFeedLink status

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

PaceFeedState status

If there were no further discussion: Like PaceSupersede, this model of publishing does not (so far) enjoy consensus support. -Tim

PacePersonLinks status

If there were no further discussion: Has failed to get anywhere near enough support to call rough consensus in previous go-arounds. -Tim

PaceIRI status

If there were no further discussion: It's hard to see how to avoid adopting this now that IRIs are standards-track RFC. -Tim

PaceSimpleLanguageTagging status

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

PaceEntryDeletion status

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

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 m

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 pic

Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS)

On Mon, 24 Jan 2005 14:52:52 -0700, Antone Roundy <[EMAIL PROTECTED]> wrote: > > On Monday, January 24, 2005, at 02:03 PM, Danny Ayers wrote: > > Atom processors MAY interpret unprefixed attribute names as their > > namespace-qualified equivalents. > > If they do, then all Atom attribute names M

AtomPubIssuesList for 2005/01/24

In consultation with the co-chairs (and Paul, I believe, will provide more details on where we go from here), I'm scheduling all the remaining format Paces. If successful, this document can move forward. If not, we will have a very good idea of what work is remaining, and hopefully can close

Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS)

On Monday, January 24, 2005, at 02:03 PM, Danny Ayers wrote: 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. I'd suggest slightly different language, such as: "Atom pro

Re: AtomAsRDF_PaceAttributesNS

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 fro

PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS)

"running code" ;-) http://www.intertwingly.net/wiki/pie/PaceAttributesNamespace == Abstract == Allow processors to interpret Atom attributes as being within the Atom namespace. == Status == Open == Rationale == Atom attributes are not in a namespace, which is likely to cause problems with i

Re: AtomAsRDF_PaceAttributesNS

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

Re: AtomAsRDF

On Jan 24, 2005, at 9:01 AM, Henry Story wrote: Text close to the following should appear in the spec (please make more precise) ... Who are you asking to make it more precise? -Tim whoever knows for example where it would be best placed in the spec, if it should replace some other sentence, if

Re: AtomAsRDF

On 24 Jan 2005, at 17:35, Tim Bray wrote: On Jan 24, 2005, at 1:02 AM, Henry Story wrote: Text close to the following should appear in the spec (please make more precise) "Processors should interpret unprefixed attributes in atom namespaced elements to be in the atom namespace" Who are you aski

Re: AtomAsRDF

On Jan 24, 2005, at 1:02 AM, Henry Story wrote: Text close to the following should appear in the spec (please make more precise) "Processors should interpret unprefixed attributes in atom namespaced elements to be in the atom namespace" Who are you asking to make it more precise? -Tim

Re: AtomAsRDF

I agree with Martin D~{(9~}rst's analysis. I have added the following to the AtomAsRDF [1] proposal. Text close to the following should appear in the spec (please make more precise) "Processors should interpret unprefixed attributes in atom namespaced elements to be in the atom namespace" This