Ok, how's this: Add to 10.1:
An atom:entry MUST contain no more than one "edit" link relation. Add to 10.2: An atom:entry MAY contain zero or more "edit-media" link relations. Joe Gregorio wrote: > On 6/12/06, James M Snell <[EMAIL PROTECTED]> wrote: >> >> PME5 is silent on the cardinality of edit-media because I didn't think >> there was any reason to specify it. We have use cases where multiple >> edit-media links are valid and very useful. Most commonly, however, >> there will likely only ever be one. Some statement that an entry MAY >> contain multiple edit-media links would be appropriate, but I'm not >> convinced it's necessary. > > 0 to 1 is fine. > 0 to many is fine. > > Remaining silent on the subject has raised questions > and the Pace isn't even folded into the spec yet, which is not fine. > > -joe > > >> >> - James >> >> Joe Gregorio wrote: >> > >> > On 6/12/06, Andreas Sewe <[EMAIL PROTECTED]> wrote: >> >> OK, so far so good. But what about the case where both the "image/png" >> >> and "image/gif" version are supposed to be editable? (The server might >> >> e.g., synchronize both versions, after an edit, by automatic >> conversion >> >> again.) >> >> >> >> In this case the entry has multiple "edit-media" links which do >> point to >> >> different resources (at least to different URIs, namely >> >> <http://example.org/media/1.png> and >> <http://example.org/media/1.gif>): >> > >> > Yeah, that's a good catch, PaceMediaEntries5 is silent on the >> cardinality >> > of 'edit-media' links and that needs to be fixed. I really don't >> care if we >> > say there can be at most one or if we allow more than one, but >> > PaceMediaEntries5 >> > does need to be clarified on that point. >> > >> >> Here RFC 4287's definition of "alternate" (every editable media >> resource >> >> is also an alternate version of the entry) unfortunately provides no >> >> hints as to the validity of the above, since its definition uses >> neither >> >> the term "resource" nor the term "representation"; it just talks about >> >> "versions". >> > >> > Yes, it appears that in some bizarre attempt to avoid WebArch >> > nomeclature some ambiguity is present in RFC 4287. I'm just shocked. >> > >> >> At any rate, is the above extended example valid with respect to >> >> PaceMediaEntries5? >> > >> > Good question, right now it's ambiguous and that obviously needs to be >> > resolved. >> > >> > Thanks, >> > -joe >> > >> >> > >
