Thomas Broyer wrote:
>
> 2006/5/4, James M Snell <[EMAIL PROTECTED]>:
>> > """
>> > 8.2 The 'edit' link relation
>> >
>> > In an Atom Entry, an atom:link element with a link relation of "edit"
>> > indicates the IRI used to retrieve, update or delete the entry.
>> > [EMAIL PROTECTED]: the next part can be ignored if the WG thinks it can be
>> > left [EMAIL PROTECTED] When no such link exists in an Atom Entry, this
>> > specification defines no other mean to discover the IRI used to edit
>> > the entry.
>> > """
>>
>> I don't see how this is better than what is currently in the Pace. The
>> second sentence is unnecessary, and the first doesn't seem to be much
>> different than what we already have.
>
> No "SHOULD", that's not a minor difference.
>
No, it's not a minor difference, I just don't see how it's better.
>[snip]
>> > I was just asking which "valid reasons in particular circumstances"
>> > are envisioned for not making this a MUST, as they're not in the
>> > proposed spec text.
>> >
>> > Actually, I can see some reasons:
>> > - "soft deletes" (instead of deleting the resource, move it to a
>> > "trashcan" from where it can be recovered),
>> > - the server knows the "media resource" is referenced from elsewhere
>> > and choose to keep the resource accessible (but no longer editable)
>> >
>>
>> Both of these reasons apply to our implementation/interop endpoint.
>> When an item is soft-deleted, it's linked resources are still around
>> until the item is purged.
>
> So I think these should be spec'd as examples of "valid reasons in
> particular circumstances" that justify a "SHOULD" instead of a "MUST"
> (I think that sort of thing – not justifying or explaining the choice
> of SHOULDs over MUSTs – was reproached by the IESG to Atom-Syntax
> final drafts).
>
Noted, but I'm going to hold off putting it in the pace for now.
>[snip]
>> ===
>> 10.2 The "edit-resource" Link Relation
>>
>> The Atom Protocol adds the value "edit-resource" to the Atom Registry of
>> Link Relations (see section 7.1 of [RFC4287]). When appearing within an
>> atom:entry, the value of the href attribute is an IRI that may be used
>> to modify a media resource associated with that entry.
>> ===
>
> What is "a media resource associated with that entry"? how is it
> "associated"? using a [EMAIL PROTECTED]"enclosure"]? using any link/@rel but
> with a non-application/atom+xml link/@type? referenced from within
> html or xhtml atom:content of atom:summary? or maybe referenced with
> atom:content/@src?
> I'd be OK to call for "media link entries" if you don't like the "an
> Atom Entry whose atom:content "type" attribute value is a media-type"
> wording.
>
I'll play with the wording a bit more in the morning to see if I can get
something better.
>[snip]
> Yep, but saying:
> """A value of "entry" indicates that Atom Entry Documents can be
> posted to the Collection. If the accept element is omitted, clients
> SHOULD assume that only Atom Entry documents will be accepted by the
> collection."""
> implies that without "entry", Atom Entry Documents with inlined
> base64-encoded image/png (for example) cannot be POSTed. However,
> adding "entry" for that purpose is also implying that text/html/xhtml
> atom:content can be POSTed, which might not be the case.
>
Agreed. So we need some kind of reading from the group to figure out how
everyone feels about posting entries with inline Base64 encoded content.
As far as I can tell, it's never been resolved.
- James
