Subject: Reducing recidivism

From: Sam Ruby <[email-masked]>
Date: Sat, 13 Nov 2004 15:44:48 -0500

Based on the responses I have seen to date, I'm not prepared to schedule 
PaceDeclareVictoryOnFormat just quite yet.

However, I do believe that it might be worth considering a small change 
to the process.

The current process is that from the pool of a few dozen paces, I select 
up to a dozen or so to discuss, and after a while, a few get closed, a 
less get accepted, and the rest are sent back to the pool.  Meanwhile, a 
few new paces get authored.

Net result is approximately a steady state.  That's not in the working 
group's best interests.

Things I don't want to do:

* Put a moratorium on new paces

* Establish a "three strikes and you are out" rule for paces

* Eliminate the possibility of reopening issues

So... the process change I would like to propose is that we focus on 
reducing the amount of Paces that simply get thrown back to languish. 
And my proposal is simple: in order for a scheduled Pace to be sent 
back, at group of people - including at least one detractor - volunteer 
to work on producing a version that they can live with.

Fair enough?

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Sat, 13 Nov 2004 18:27:23 -0500

> Net result is approximately a steady state.  That's not in the working 

Please consider closing a bunch of link Paces per
http://www.imc.org/atom-syntax/mail-archive/msg10800.html

> to work on producing a version that they can live with.

Yes.

Robert Sayre

---

From: Danny Ayers <[email-masked]>
Date: Sun, 14 Nov 2004 11:44:06 +0100

> http://www.imc.org/atom-syntax/mail-archive/msg10800.html

I've just been through these to try and clear up any I've been anywhere near.

The following two I've updated to - "Status: Closed (superceded by
PaceFieldingLinks)"

PaceLinkRelUri - essentially the same as PaceFieldingLinks (but using
the Atom namespace rather than registering)

PaceLinkRelMechanism - earlier RFC2731/QNames version of the above

There is a little overhang: these included a title attribute to
provide a label - might this still be desirable with
PaceFieldingLinks? There's also "rev" - might that still be useful? (I
don't see the need for @type any more).

LinkTagMeaning - this desperately needs refactoring. 
What is the status of PaceReplaceLinkElement?

> > to work on producing a version that they can live with.

Worth a try. 

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Eric Scheid <[email-masked]>
Date: Sun, 14 Nov 2004 22:21:02 +1100

On 14/11/04 9:44 PM, "Danny Ayers" <[email-masked]> wrote:

> (I don't see the need for @type any more).

I do.

    <link rel="comments" type="text/html" href="..." />
vs
    <link rel="comments" type="application/atom+xml" href="..." />

or...

    <author>
        <link rel="about" type="application/FOAF+xml" href="..." />
    </author>

@type is better than heading the links for a couple of reasons:

1) you've already got the string in hand
2) servers are notoriously bad at providing the correct mime type
3) more likely to be accurate than the server
4) more likely to communicate the intent of whoever wrote the link

e.