[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: issue: draft posts



On Tue, 22 Mar 2005 18:14:20 -0500, David M Johnson
<Davidm.Johnson@xxxxxxx> wrote:
> I think you're talking about PacePubControl:
> http://intertwingly.net/wiki/pie/PacePubControl
> 
> Which I thought was pretty good.

D'oh. I knew I'd seen a Pace that did this but couldn't find it. I
like this Pace and would make the following suggestions:

1. The way the prose is written it sounds like if you do a 
    GET on an entry then it wouldn't have a <control/> 
    element, which I believe must be there for this to be useful.
    Don't make any distinctions based on the verb, but only describe
    the elements on what they mean for the state of the entry.
    Of course, given that, you might want to reconsider the name
    <control>.
2. Follow Danny's suggestion and not make the values controlled 
    by a registry, but instead allow extension by adding in new child
    elements from a different namespace.
3. Drop the seperate namespace for <control> and all 
    it's children that are defined in this spec, they should be in the 
    Atom namespace.

The only one I think needs more justification is #2.

We created the registry for the link @rel values, why not use a registry
here? I think context makes a difference. In the case of link @rel
the values show up in a feed and it is fairly easy to change and/or add
new values to a feed given todays weblog editing systems, usually it just
involves editing a template. In the case of pub:control, however, the
extensions are
only going to be defined by either the makers of weblog editing
clients that support
the APP or servers that support the APP. That is a much smaller pool. Of course,
the amount of extension required will reflect on how much work we do on the 
inital set of children for pub:control.

    -joe

-- 
Joe Gregorio        http://bitworking.org