2006/5/7, Bill de hÓra <[EMAIL PROTECTED]>:
It doesn't address population of compulsory entry feeds *, notably author, id.
"author" can be populated based on some server configuration (in a single-user system), the authenticated user, some metadata embedded in the POSTed non-Atom content, a default "anonymous" (or "unknown") value until it's been edited.
Why is only title supported - bug compatibility with 08?
The only reason I see for this header is for clients to suggest a "slug" (I mean, something to be reflected into the resource IRI). Everything else could be edited later. I'd personnaly prefer a "Slug" header or, better, as involving no invention, using the Content-Disposition header and its "filename" parameter value. Have you other solutions?
The workaround for summary/content is noted (though I somehow doubt that's what the syntax wg had in mind)
Which workaround are you talking about?
It doesn't rationalize rel="edit-resource". And it needs to; editing non-header metadata about a resource v editing the resource is a first class webarch headache. How many resources are in play with a media entry?
I personnaly believe there is only one, with different representations. There is the "original" representation (the one that have been POSTed/PUT, or eventually a transformed one) and an Atom Entry Document representation. The Atom Entry Representation could include the "original" representation inlined in the atom:content element, but that might not be optimal in many cases, so it might be better to reference it. This means that there is a single resource, with at least two representations, each being accessible via distinct IRIs (and it would be best if they were also accessible using conneg on a single IRI, but I seem to remeber that the WG wasn't inclined into having conneg a mandatory aspect of the protocol). So I think rel="edit-resource" should be rel="edit", using client-side conneg based on atom:link/@type (actually, this is not really "negotiation", rather a simple "choice"). That might not be the WG's consensus, but, well, this is my opinion, which I think doesn't abuses the webarch or REST. My goal is to have metadata editable both as an Atom Entry Document, using GET and PUT, and as resource properties, using PROPFIND and PROPPATCH.
I have a niggling worry that this header based stuff can't be supported via regular HTML forms,
Regular HTML forms send "files" as multipart/x-www-formdata, so they are not compatible with the current design of the protocol which intends to be compatible with WebDAV.
and thus the protocol doesn't provide a natural upgrade/adoption path without doing an end run around browsers
Nothing prevents writing a "browser binding" spec, to be adopted by APP servers, making them "compatible" with regular HTML forms.
(maybe javascript write out headers?).
As already noted, javascript can write out headers using "XmlHttpRequest" objects, but browsers generally don't grant scripts file system access rights, so reading files is not possible (which seems to be a requirement to send images or other documents from a browser). To be accurate, this is however possible using signed scripts.
Excluding most deployed HTTP clients should be a conscious thing.
How many people are reading RSS/Atom feeds "as-is" on their browsers? I mean, without using web-based aggregators (acting as some kind of "proxies" transforming data to HTML) or browser extensions/plug-ins.
* 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.
I'm affraid I can't agree. Would it help if the examples were using empty values? <author><name/></author> <summary/> or some "default values"? <title>A picture of the beach</title><!-- comes from the Title: header --> <author><name>Unknown</name></author> <summary>A picture of the beach</summary> -- Thomas Broyer
