On 5/7/06, Bill de hÓra <[EMAIL PROTECTED]> wrote:

-1 (as of 7th May 2006)

It doesn't address population of compulsory entry feeds *, notably
author, id. Why is only title supported - bug compatibility with 08? The
workaround for summary/content is noted (though I somehow doubt that's
what the syntax wg had in mind)

It doesn't rationalize rel="edit-resource".

First, I agree with your comments elsewhere that this should
be renamed. rel="edit-media" would be more appropriate.

And it needs to; editing
non-header metadata about a resource v editing the resource is a first
class webarch headache.

I don't see a web arch problem here.

How many resources are in play with a media entry?

Does it matter? There are two URIs that have different
representations, whether or not those are the 'same' resource
is a server implementation detail and as far as I can tell
has no impact on the interop of the protocol.

I have a niggling worry that this header based stuff can't be supported
via regular HTML forms,

We are talking about POSTing XML which automatically
excludes traditional web forms, and has for every iteration
of the protocol we've ever talked about. This is not new
and has nothing to do with this Pace.
(As others have pointed out XMLHttpRequest supports adding
headers to requests, but that's orthogonal to HTML forms.)

 and thus the protocol doesn't provide a natural
upgrade/adoption path without doing an end run around browsers (maybe
javascript write out headers?). Excluding most deployed HTTP clients
should be a conscious thing.

cheers
Bill

* Comment from James Tauber on something I wrote elsewhere about this:

"This magic is currently required in -08, with or without
PaceMediaEntries3."

No matter, I'll being taking this pace series on its merits. If it gets
rejected, we can talk about bugs in 08.




--
Joe Gregorio        http://bitworking.org

Reply via email to