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.
Editorially speaking, it describes what the "edit" link relation is
for, without putting constraints on when, how and why to use a link
with such a link relation.
I'm OK that the last sentence is not that good, after all ;-) I didn't
want to say that "an entry without such a link is not editable"
because when you issue a GET to the [EMAIL PROTECTED]"edit"]/@href, the
returned Atom Entry Document might not have an atom:[EMAIL PROTECTED]"edit"]
(you already have the "edit IRI").
> 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).
> How about:
> """
> 10.2 The "edit-resource" Link Relation
>
> In an Atom Entry whose atom:content "type" attribute value is a
> media-type, an atom:link element with a link relation of
> "edit-resource" indicates the IRI used to update the entry content.
> """
>
I changed the text in the Pace to:
===
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 also updated the text for section 10.1,
===
10.1 The "edit" Link Relation
The Atom Protocol adds the value "edit" to the Atom Registry of Link
Relations (see section 7.1 of [RFC4287]). The value of "edit" specifies
that the value of the href attribute is the IRI of an editable Atom
Entry Document. When appearing within an atom:entry, the href IRI may be
used to update and delete the resource represented by that entry.
===
OK, except that I wouldn't expect the following link to point to an
Atom Entry Document:
<link rel='edit' type='image/jpeg' href='…' />
===
The app:collection element MAY contain one "app:accept" element. The
app:accept element value specifies a comma-separated list of
media-ranges [RFC2616] identifying the types of representations that may
be POSTd to the Collection's URI. Whitespace separating the media-range
values is considered insignificant and MUST be ignored.
The app:accept element is similar to the HTTP Accept request-header
[RFC2616] with the exception that app:accept has no notion of
preference. Accordingly, the value syntax of app:accept does not use
accept-params or "q" parameters as specified in [RFC2616]. The order of
media-ranges is not significant. The following lists are all equivalent:
<app:accept>image/png, image/*</app:accept>
<app:accept>image/*, image/png</app:accept>
<app:accept>image/*</app:accept>
===
OK
>> The accept represents what you can POST to the collection, not
>> necessarily what the collection can contain. For instance, I would
>> consider it appropriate behavior for a server accepting image/png POSTs
>> to create entries containing inlined, base64-encoded image/pngs as
>> opposed to using the src attribute. But that's just me.
>
> That wasn't my point.
>
Sorry, I did get your point, I just didn't communicate it very well ;-)
I personally don't see a problem with a server accepting an inlined
base64 encoded content element, however, I can definitely see how doing
so could cause problems. I'd leave it unspecified and let server
implementors sort it out.
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.
> How about discussing app:accept separately from "media entries"?
> app:accept could very be taken outside PaceMediaEntries and put into
> another Pace of its own, without making PaceMediaEntries less
> consistent.
Well, the problem with that is that the "cat blog" scenario doesn't work
too well without it. And at this point, we seem to have lots of heads
nodding in agreement with what we've got.
I can't see why. The "POST a non-Atom Entry Document results in the
creation of an Atom Entry Document with content/@src referencing the
non-Atom Entry resource" thing works very well with app:member-type,
no need for app:accept for this to work (the "cat blog" scenario
seemed to work with the current draft, because the notion of "primary
collections" was added).
I think app:accept is far better than app:member-type, but it can be
discussed separately.
--
Thomas Broyer
