Re: [xml-dev] Mime type for compound document.

["bryan rasmussen" <rasmussen.bryan@gmail.com>]

> Is it the case then that every time someone creates a new namespace
> they have to create a new MIME type to go with it?! Doesn't that rather
> damage the whole concept of extensibility in XML? I appreciate some
> namespaces are more equalt than others but at what point should a
> MIME type be created?

I would say the following:

1. My personal feeling if the XML format is a 'data' format it does
not need a mime type.
2. If it is a 'code' format then it should have a mime type.

what entails a code format. hard to say, my gut feeling would be well
code formats are SVG, XHTML, XML Schema, XSL-T, Schematron....

but maybe that is not a rigorous enough explanation. Perhaps a
rigorous explanation would be that a code format is a format that must
be executed to know what the actual content of the XML is, this allows
in XHTML and SVG because these formats interact with scripting (and in
the AJAX web are just envelopes for a JavaScript to run - a bad thing
I believe), it accepts XSL-T and Schematron(with most bindings)
because these are Turing complete - I may be wrong about Schematron at
this point. But it would lock out XML Schema - oh well. Perhaps
someone else could specify a rigorous definition of code format that
allows XML Schema into the list but locks stuff like UBL out.

Another idea might be a format should have a mime type if it is
expected to be retrieved over http in a manner that can affect it's
actual processing, and that this expectation is specified in the
specification of the format.


XML Schema with xsi:schemaLocation
XSL-T when running in the browser
RSS/ATOM and so forth

Finally, I am not watching anything about current standardization in
the mime type space, I would hope something is going on that would
allow one to specify that sort of thing in an extensible manner. The
accept header does something along those lines:

for example if you did

 Accept: application/xml, application/{your type of XML}+xml;q=0.9

and the server application had something that checked that the mime
types accepted was in an array of mime types served and then picked
the right mime type out dependent on the quality parameter of the
accept header

then you would be able to better return the mime type. In the list of
mime types accepted it accepts less specific mime types so there is
some sort of rough extensibility.

I think though what is wanted is some additional header fields for XML
documents.
So the mime type should stay application/xml

but then in the header fields you might have such things as

NamespacePrimacy:http://www.example.org/namespace1,http://www.example.org/namespace2

The idea being that with a NamespacePrimacy the list of namespaces
tells us what are the most important namespaces to process in the
document.

This would be useful because one could do a request for that header on
a resource that had an application/xml mime type and dependent on if
the namespace was in the list of processable namespaces decide as to
whether or not the full GET on the resource should be done.

I suppose however that there are people who have something similar or
better under works somewhere and I am just unfamiliar with it.

Cheers,
Bryan Rasmussen


> a similar matter - when does a new namespace merit a
> new file extension being registered? We have .xml for most things but
> what are the guidelines for whether or not to register a special extension?
> Surely there is merit in just using .xml so an application knows it is
> XML (if I called an invoice abc.ubl rather than abc.xml the applications
> won't know it is XML and probably won't know what ubl is anyway). I
> guess the same applies to MIME type. If I send a file as schematron
> MIME type then the receiver which doesn't recognise that MIME type
> won't recognize it as XML either, surely. So there must a critical mass
> point at which there enough apps which would recognize it to warrant
> using it. The question is: will that point ever be reached and is it worth
> all the pain in the meantime having folk send me files my system doesn't
> recognize as either XML nor Schematron.
>
> Best regards
>
> --
> Stephen Green
>
> Partner
> SystML, http://www.systml.co.uk
> Tel: +44 (0) 117 9541606
>
> http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
>
>
> On 06/12/2007, Dave Pawson <davep@dpawson.co.uk> wrote:
> > On the dsdl list, a request arose for
> > the mime type for a Schematron document.
> >
> > It appears that for compound documents, no one has
> > got to grips with mime types as yet.
> > The issue is, as  Makoto MURATA  put it,
> >
> > A schematron schema can be embedded within NVDL scripts, RELAX NG
> > schemas, W3C XML Schema schemas, XProc scripts, and so forth.
> >
> >
> > Ken Holman said, intriguingly,
> >
> > Hasn't this issue been around since 1999?  I recall the tension
> > between the "Internet guys" who believe the MIME type should reveal
> > everything without the need to look inside (so
> > "application/schematron+xml" or "application/xslt+xml" is necessary)
> > and the "XML guys" who believe that XML already has identification
> > built in with namespaces when you look inside (so "text/xml" is sufficient).
> >
> > I don't believe this was every resolved or could be resolved because
> > of the intractable positions of those who do not want to look inside
> > of the file and those who don't mind doing so.
> >
> > Do we have both 'internet guys' on this list, as well as
> > xml guys (and gals I guess)?
> >
> >
> > Mime type of the outer wrapper?
> > Metadata pointing to the inner variants?
> > Other options?
> >
> > Intractable? Doubtful.
> > Permathread fodder? Possible.
> >
> >
> >
> > regards
> >
> >
> > --
> > Dave Pawson
> > XSLT XSL-FO FAQ.
> > http://www.dpawson.co.uk
> >
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>