Re: Searching for concensus on Pub Control (Re: Consensus call: PacePubControl)

["Thomas Broyer" <t.broyer@xxxxxxxxxxx>]

Joe Gregorio wrote:
>
> I'd like to know how people feel about the following statements. Feel
> free to either +/- 1 them or, for example, say that the MUST needs to be
> a SHOULD, or MAY. I've worded these all strongly to hoepfully prod more
> people into responding :)
>
> When I say Control Information, let's just assume that's restricted to
> 'draft=yes/no' for now.
>
> 1. Control information MUST be sent with the initial POST to create an
> entry.
>     (otherwise creating a draft is a two step process.)

+1,

but I'd rather say that otherwise, creating a *non-draft* is a two step
process (I'd expect resources to be drafts by default, because not all
servers will allow you to turn from non-draft to draft).

> 2. Control information MUST be sent with the initial POST to create a
> non-entry member.
>
> 3. Non-entry collections MUST support control data.

I'm not even sure what non-entry members are meant to be... Is APP a
simpler FTP (where you don't bother creating directories, but you must
however create collection...) ?

A photo collection is (in my mind) just a collection of entries whose
atom:content is a base64-encoded image (or using @src to reference another
part in a multipart/related structure, what I call Compound Entry),
because I want to attach a title, a short description, keywords, etc. to
the photos...

> 3. Control information MUST be able to be set separately from updating
>     an entry via PUT. (because the overhead of PUTing the complete entry
>  is too much overhead)

+.5 don't know whether it's a must-have, at least it is a nice-to-have...

> 4. Control information MUST be extensible.

+1

> 5. Control information MUST be in an XML document.

+1

because: see below + consistency in defining extensibility mechanisms...

> 6. Control information MUST be contained inside the entry document.

+1

-- 
Thomas Broyer