James Tauber wrote:
On Sun, 07 May 2006 10:20:45 -0700, "Tim Bray" <[EMAIL PROTECTED]> said:
Your other points aside, I just don't see a problem here. You do a
POST, and as a consequence two resources are created: one is a "Media
resource" containing whatever the body of your post represented, the
second is a "Media link resource" which, irrespective of what kind of
thing you posted, is represented by an Atom Entry and which describes
the Media resource. Totally within the semantics of POST,
Given POST semantics are determined by the server wrt the URI being
POSTed to, that's not saying much.
I see no
webarch tension here at all. In fact the whole thing feels elegant
and minimal to me. You want to update the metadata package, you
update it. You want to update the picture of the cat, do that too.
The two are decoupled and [important to me] not hard to explain. -Tim
Agreed. In this case, APP cares about two resources:
[...]
I have a problem reconciling "not hard to explain", the rest of James
T's post, and the pace put in front of us.
As things stand I'll always have to work through the metadata, since we
don't mandate resource refers to its metadata. That's probably ok in the
general sense (we love how 404 scales), but given we've just posted a
non-atom asset thingie to an APP store, and both the asset and the
metadata are in the same authority, it seems no biggie to point to the
metadata when serving the asset. Presumably without that I need a query
supported on the server to obtain the metadata - something we do not
specify here. Good luck with that across clients and servers.
We'll also have to update the model section to reflect that the core
distinction between "media resources" and "atom resources" is that media
resources have an associated atom entry as a byproduct of being plopped
into an APP aware store. At least that's a testable distinction and gets
us away from defining a media resource in terms of what it is not.
Editorial. Either the rel values "edit" and "edit-resource" go, or the
terminology "media resources" and "media link entries" do - these things
need to be evidently symmetrical. Given two resources, any spec verbiage
that wants call only one of them a 'resource' in preference to the other
is tortured, and to be avoided. [If we can't spec this without using
"resource" in this way, I submit we do have a modeling problem.] The
pace will need other work - copy like "A media resource is typically
non-textual", "or from any other source", "may or may not", aren't
operationally useful, and might even be misleading.
I still have a problem with the Author magic. I suspect strongly that
anyone who's implemented this and had no problem in doing so "happens"
to know who the author is already, i.e., it's stateful.
cheers
Bill
