Luke Arno wrote:
On 10/27/05, Joe Gregorio <[EMAIL PROTECTED]> wrote:
On 10/27/05, Luke Arno <[EMAIL PROTECTED]> wrote:
We can use *both* mime types.
Are you advocating using content negotiation?
No way. I personally would just serve the same doc
from two URIs or using a query parameter.
I'm just being anal about language use here, but: serving "the same doc
from two URIs or using a query parameter" *IS* content negotiation:
From RFC2616
<snip>
12.2 Agent-driven Negotiation
With agent-driven negotiation, selection of the best representation
for a response is performed by the user agent after receiving an
initial response from the origin server. Selection is based on a list
of the available representations of the response included within the
header fields or entity-body of the initial response, with each
representation identified by its own URI. Selection from among the
representations may be performed automatically (if the user agent is
capable of doing so) or manually by the user selecting from a
generated (possibly hypertext) menu.
</snip>
What I suspect you mean is that you're not advocating the use of things
like Vary and Accept for content negotiation which would add a higher
degree of complexity to the whole thing.
In general, what you're suggesting here is fine. There is no apparent
downside at all in allowing an introspection document to be served up in
browser displayable format but I would highly recommend that we make it
a requirement that APP implementations at the very least, serve up the
introspection format using a unique mime type we can dispatch off of.
If those implementations also want to serve up the introspection
document using a browser-friendly mime type, so be it, more power to
them, but doing so should be entirely optional given that no case has
yet been presented that introspection documents MUST be viewable in the
browser. Further, I recommend that we create a <link
rel="atom-introspection" /> that would sit at the top of a (X)HTML page
as the standardized way of pointing to the URL used to serve up the
Introspection document with the APP specific mime type.
Taking this approach actually does not require us to change anything in
the existing specification (beyond potentially adding <link
rel="atom-introspection">). That is, there is nothing in the current
spec that forbids introspection documents from being served up using
some other mime type and there is no need to tell people that doing so
is permissible given that doing so would serve no required functional
purpose. (Example: Sam Ruby is serving up his Atom feed as
application/xml rather than application/atom+xml, which is perfectly
legitimate even tho the Atom spec does not explicitly allow it)
- James
