2006/5/4, James M Snell <[EMAIL PROTECTED]>:
> It might also be useful either a) paraphrasing RFC2616 saying that
> Content-Location might be a relative URL (relative to the request URI)
> or b) spec'ing that Content-Location values must be absolute URLs in
> the context of the Atom Publishing Protocol.
> I'd prefer b), a bit easier to implement for clients, and a noop for
> servers (well, except eventually for some cases where they provide a
> Content-Location with a value different from the Location value)
Can you offer some suggested spec text that I can work into the pace?
In the previously suggested paragraph, change the sentence about
Content-Location to "and the response contains a Content-Location
header with the same value *character-by-character* as the Location
header".
> """
> 8.2 The 'edit' Link
>
> Each member Entry within a collection SHOULD contain an atom:link
> element with a link relation of "edit" that contains the IRI used to
> retrieve, update or delete the member Entry.
> """
>
> I thought this was changed to a MAY. How about just describing the
Not sure, I was basing this on what is actually in the current draft text.
> "edit" link relation meaning and either leave implicit or explicitly
> say that an entry in a collection listing without an [EMAIL PROTECTED]"edit"]
> is not editable.
> (Note that it's not really clear per the actual wording whether an
> entry retrieved through its [EMAIL PROTECTED]"edit"] should in turn also
> contain such a link or not)
Again, suggested spec text would be helpful.
"""
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 think this is precise enough for interoperability and not too
precise to not put constraints where they're not needed (it doesn't
say what a [EMAIL PROTECTED]"edit"] at the feed level means or whether the
absence of a [EMAIL PROTECTED]"edit"] in an Atom Entry Document means it's
not editable: client implementations can still issue an OPTIONS on the
request URI or try a PUT or DELETE and see what happens)
> """
> Deletion of a media link entry SHOULD result in the deletion of the
> linked media resource.
> """
>
> Any reason to make it a SHOULD rather than a MUST?
Any reason to make a MUST rather than a SHOULD? ;-)
From RFC2119:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
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)
> How about adding something like
> """This specification assigns no significance to atom:link elements
> with a link relation of "edit-resource" as direct children of
> atom:feed elements, or within entries whose atom:content "type"
> attribute value is not a media-type (e.g. the attribute is absent or
> its value is one of "text", "html" or "xhtml"): because those contents
> have no media-types, they cannot reliably be sent over HTTP outside an
> Atom Entry."""
-1, don't think this is necessary. e.g. we don't say similar things
with regards to any other link relation.
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'm not using the "media link resource" term, because implementations
might choose to use a [EMAIL PROTECTED]"edit-resource"] to update an inlined
"media-typed" content (such as text/calendar or image/svg+xml).
> """
> The app:accept
> element value specifies a comma-separated listing of media-ranges [RFC2616]
> identifying the types of representations that may be POSTed to the
> Collection's URI.
> """
> Still lacks something about "qvalues" and "accept-parameters" ;-)
> maybe also something about prevalence of "wildcard media-ranges" over
> "media-type media-ranges", e.g. what does this mean: <accept>image/*,
> image/png</accept>
Again, suggested spec text would be helpful. I'll incorporate it into
the pace.
"""
The app:accept element value specifies a list of media-ranges
[RFC2616] identifying the types of representations that may be POSTed
to the Collection's URI. Media-ranges are separated by one or more
commas, and OPTIONAL whitespace [REC-XML]. In that sense, the
app:accept element is similar to the HTTP Accept request-header field
with the exception that app:accept has no notion of preference, thus
its value syntax has no accept-params or "q" parameters. As there is
no notion of preference, the order of media-ranges is not important;
therefore, 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>
"""
> """
> A value of "entry" indicates that Atom Entry Documents can be posted
> to the Collection.
> """
> I assume it implies that when this value is not present in the list,
> the collection doesn't accept Atom Entry Documents?
Right.
> Given that any collection member has an Atom Entry "representation"
> (or call it "description" if you want for "media link entries"), be it
> editable or not, then if a server accepts image/png, why couldn't it
> also accept an Atom Entry Document with an inlined, based64-encoded
> image/png?
> I understand that it's meant to represent text/html/xhtml
> atom:content/@type values but it's really not clear per this Pace.
>
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.
Give, that any collection member has an Atom Entry representation, if
a server accepts the following and produces an Atom Entry
representation from it:
POST /collection HTTP/1.1
Host: example.net
Content-Type: image/png
Content-Length: nnn
Title: A picture of the beach
[binary image/png]
Why couldn't it also accept this:
POST /collection HTTP/1.1
Host: example.net
Content-Type: application/atom+xml
Content-Length: nnn
<entry xmlns="...">
<title>A picture of the beach</title>
<content type="image/png">[base64-encoded image/png</content>
…
See this recent "request" from James Holderness:
<http://www.imc.org/atom-protocol/mail-archive/msg04934.html>
However, I'd also expect every collection to automatically accept a
POST in the form of an Atom entry document.
[…]
Its accept types might be something like "image/*; audio/*". The usual
way of adding to the collection would be to POST a chunk of binary
data (e.g. a jpeg image) and let the server extract metadata from its
EXIF block. However, just like the entry collection you could also POST
an Atom entry document with the jpeg embedded as a base64 content
element.
[…]
Similarly, if you can update an entry in an entry collection with a
single PUT containing both metadata and the entry content, you
should be able to do the same thing in a media collection, updating
the binary data at the same time as the metadata by base64 encoding
it in the content element (as unlikely as that may seem).
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.
Actually, "media entries" and app:accept are somewhat orthogonal…
I'd prefer PaceMediaEntries to be accept quickly without app:accept
than being discussed some more weeks just about this particular
section…
My 2 €-cents…
--
Thomas Broyer
