- From: "Rushforth, Peter" <Peter.Rushforth@N...>
- To: Mike Sokolov <sokolov@i...>
- Date: Mon, 10 Sep 2012 14:49:44 +0000
|
Hi Mike,
Lots of resources on the web use content negotiation over format.
For example, the w3c servers use text/html as the format for 406 responses, even for resources which do exist as application/xml variants.
Another example might be offering your blog as RSS or Atom. This seems quite common.
Yet another example might be where an image is offered as image/jpeg for size and image/png for quality.
But there's no reason it should be limited to error responses. Why not provide a text/html version of an 'application/xml' or 'application/atom+xml'
resource?
http://geogratis.gc.ca/api/en/nrcan-rncan/ess-sst/
can be negotiated as html, xml, atom, json etc., via Accept.
Cheers,
Peter
In my experience the content negotiation Peter is referring to is used almost exclusively for choosing a resource in an appropriate (human) language. I've never seen it used for mime type negotiation: people usually seem to use different URLs to represent
the same resource in different formats. Peter, can you point to any examples where the same resource is served in multiple formats using content negotiation that are in common practice?
-Mike
On 09/10/2012 09:30 AM, Rushforth, Peter wrote:
1CD55F04538DEA4F85F3ADF7745464AF1AE50CFC@S..." type="cite">
> I don't understand what this means. For example, xsi:schemaLocation?
xsi:schemaLocation _is_ a typed link, the type is implied by the design/context of this attribute. It's just that
there's no media type apart from application/xml to go with it.
Regarding
http://www.w3.org/2001/xml, when accessed with no media type preference, you get application/xml
with an xml-stylesheet PI which styles the result to HTML. However, most
'properly configured web servers' would
provide an html representation and an xml representation, and not use the
xml-stylesheet trick.
Take xsi:schemaLocation="http://www.w3.org/2001/xml" On
a 'properly configured web server', there would be
different representations of that resource, and it would be up to the client
to negotiate for the right one. There
would likely be a default representation, one which would be served in
the absence of an Accept header, or where
the media type ranges provided by the Accept value could not be honoured.
Mostly on the web this is text/html,
but where the most common use is in an xml toolchain it makes sense to
make the default application/xml,
as is the case here.
> The content-type of a resource is independant of any entity which links to it.
Yes. But there can be more than one view of that content type.
Cheers,
Peter
> Because there are no typed links in XML so it is impossible for the
> client to disambiguate except perhaps by context / hardcoding?
I don't understand what this means. For example, xsi:schemaLocation? If you fetch a document at that link, or you fetch an XSD document as Roger initially did, any properly-configured web server will return that with an XML
content-type. The content-type of a resource is independant of any entity which links to it.
/r$
--
STSM, WebSphere Appliance Architect
https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/
|
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
|