Bill, Bill de hÓra wrote: >[snip] > 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.
Hmm.. I'm having a hard time following what you're talking about here. First, posting non-aom asset thingies to APP collections is not something that PaceMediaEntries is introducing. That idea has been around for quite some time now; as has the problem about magic metadata. After writing two APP server implementations and three clients, I have yet to come across a situation in which the magic metadata thing has been a problem. Regarding your last sentence above, I have absolutely no idea what that means. You post some kind of resource, an Atom entry is created, it shows up in an Atom feed and at a particular URI. If the entry is associated with a media resource, that also shows up at some particular URI. A Location header, edit and edit-resource links point to the various pieces. What's difficult to understand about that? > > 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. > Why? > 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 Ok, "edit-media"... whatever. - James
