[
Lists Home |
Date Index |
Thread Index
]
well this is one of the subjects I'm talking
about, namespaces in a document can in fact
be pertinent to which mime type it should
have, so this is something I'm doing, the
only viable solution it seems to me, until I
get a chance to look over some of the other
stuff people have pointed me to, is to add
application specific headers to the http
response that tell a requesting application
what namespaces are in the document, I say
the only viable solution as it is the only
thing I can think of that won't break most
applications that call it, or at least have
unintended side effects. It is of course
somewhat process intensive, but our
application has a module structure so any
server hosting it could just choose to drop
the mime reporter module.
As a side issue, as I have a liking for REST
as opposed to SOAP, this seems to me to be a
good component for any application hoping to
provide a REST-ful interface to this xml
resources.
> an idea would be try to comine mime type
with namespaces (but how? ;=)) if
> you need to know what is the content type
before opening the file and reads
> the namespaces.
>
> What do you think of that?
> -----Message d'origine-----
> De : bryan [mailto:bry@itnisk.com]
> Envoye : vendredi 19 septembre 2003 13:39
> A : 'Nicolas Toper'; xml-dev@lists.xml.org
> Objet : RE: [xml-dev] mime types and xml
dialects
>
>
>
> Well if X wants to get instances of a
particular xml or rdf dialect, but
> X knows that said dialect is most
generally represented as
> application/xml+rdf then currently X has
to get the whole resource, and
> then parse the resource to find out if it
is indeed the dialect they
> want to retrieve. As a general rule the
mime type of a dialect is given
> at the above level of granularity because
web server mime type
> assignments take place at a very high
level, i.e. extensions, or
> locations, or at best, a combination of
extensions and locations.
>
> However if X knows that they can check if
the application is of a
> specific type, by checking a Header at the
beginning of crawling a site,
> then X can probe various headers to
determine what mime types a resource
> can be interpreted as before consuming
bandwidth by actually getting the
> resource.
>
> This is a general usage example, and not
deeply thought on so it could
> very well be a general uselessness
example :) however as I am currently
> implementing some specific functionality
for an application, pertaining
> to setting Mime types and headers to
convoluted to go into here (in
> short getting a vcard in xml format, and
returning it as xml or setting
> up a processing chain to get it as text/x-
vcard) it struck me that what
> I was doing was in some ways related to
problems of getting the proper
> resource, and in telling a consumer what
the resource actually is.
>
>
> -----Original Message-----
> From: Nicolas Toper
[mailto:ntoper@jouve.fr]
> Sent: Friday, September 19, 2003 12:35 PM
> To: xml-dev@lists.xml.org
> Subject: RE: [xml-dev] mime types and xml
dialects
>
> Sorry I don't understand why you're doing
this? Could you explain it to
> me
> please?
> ;=)
>
> nicolas
>
> -----Message d'origine-----
> De : bryan [mailto:bry@itnisk.com]
> Envoye : vendredi 19 septembre 2003 12:32
> A : xml-dev@lists.xml.org
> Objet : [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>
>
>
>
> -------------------------------------------
----------------------
> 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>
>
>
|
