[
Lists Home |
Date Index |
Thread Index
]
it could be extended, but I bet a lot of
people's code would prove to be affected by
such an extension.
the main question is how to decide what to
serve a resource as, as opposed to the
presentation side of my application, where
users move from the general presentation
possibilities to the specific it seems to me
that it's most logical to serve the most
specific mime type applicable to the
resource first, or one could be pragmatic
and serve the most common version of a
format; i.e. in the case of vcard that is
rdf+xml process the resource to an x-vcard,
set the mime type, and add application
specific response headers whereby a client
can find out that the resource their
response was derived from is also available
as rd+xml and so forth.
>
> I meant to add to that: the trick that's
used with
> xml formats might be extended to rdf+xml-
based formats.
>
> Assuming someone created a media type that
was based
> on rdf+xml, it seems that the trick of
parsing the
> mime type would be handy if it was
something like
> blah/vcard+rdf+xml
>
> But then, I have a love-hate relationship
with
> media types as currently concieved, so I
could change
> my opinion on that.
>
> - Chris
>
> -----Original Message-----
> From: Chris Wilper
> Sent: Friday, September 19, 2003 10:36 AM
> To: bryan; xml-dev@lists.xml.org
> Subject: RE: [xml-dev] mime types and xml
dialects
>
>
>
> HTTP 1.1 has content negotation:
>
http://www.w3.org/Protocols/rfc2616/rfc2616-
sec12.html#sec12
>
> But you might be after something simpler.
> Ideally your xml-based formats would have
their own media types,
> and the fact that they end in "+xml" (as
they should) would
> signal to a client that they can be
processed in either a
> specialized or generic way.
>
> - Chris
>
> -----Original Message-----
> From: bryan [mailto:bry@itnisk.com]
> Sent: Friday, September 19, 2003 6:32 AM
> To: xml-dev@lists.xml.org
> Subject: [xml-dev] mime types and xml
dialects
>
>
>
>
>
> Hi,
>
> When returning a mime type of a resource,
if that resource is a dialect
> of xml then the more general type is
text/xml but the more specific type
> can be application/rdf+xml which in turn
can be even more closely
> specified as a subset of RDF.
>
> Currently what I'm doing is returning
text/xml for generic xml
> documents, and application/rdf+xml for all
dialects of rdf; what I'm
> considering is the possibility of adding
http headers that specify that
> there is a range of mime types possible
for a resource, and their
> likelihood of being the best type for a
resource.
>
> Anyone done anything with that, pointers
to discussions, projects and
> similar stuff in the past would be helpful.
>
>
>
>
>
>
>
>
> -------------------------------------------
----------------------
> The xml-dev list is sponsored by XML.org
<http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-
open.org>
>
> The list archives are at
http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list
use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
>
> -------------------------------------------
----------------------
> The xml-dev list is sponsored by XML.org
<http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-
open.org>
>
> The list archives are at
http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list
use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
>
> -------------------------------------------
----------------------
> The xml-dev list is sponsored by XML.org
<http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-
open.org>
>
> The list archives are at
http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list
use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
>
|
