A few points:
1. "x-" is commonly used in cases when an application for a mime type is
pending, and when there is a reasonable expectation that it will be
approved. The mime type is prefixed with "x-" until the requested mime
type becomes official, after which the "x-" is dropped.
2. We will be registering MODS and MARCXML:
- application/mods+xml
- application/marcxml+xml
3. The reason one uses (or doesn't use) +xml is made very clear in one of
the relevant RFCs (I don't have the number at the moment): the application
consuming the content is supposed to recognize the mime type and process it
accordingly, however, in the event that it does not recognize the mime type,
the "+xml" signals at least that the content is xml, and so there is a
possibility that it might do something useful with it, even though it cannot
proccess it according to mime type - it may be able to parse the XML and
present something readable to the user. Even better, consider the case
where it is a protocol response, for example SRU, where we are registering
application/sru+xml, there might be an accompanying stylesheet url, and the
client can then format a complete sru response without knowing that it did
so.
The reason is NOT, as some have suggested, to distinguish "mods+xml" from
"mods+xyz" where "xyz" is some alternative syntax. However, because of the
confusion, we would register marcxml as marcxml+xml (even though it sounds
funny) rather than marc+xml, because of all the confusion that the latter
name would cause.
--Ray
----- Original Message -----
From: "Jonathan Rochkind" <[email protected]>
To: <[email protected]>
Sent: Thursday, February 12, 2009 5:21 PM
Subject: Re: [CODE4LIB] MIME Type for MARC, Mods, etc.?
Actually, re-reading some of the RFCs, I would clarify one thing.
It seems like using unregistered "x-" MIME type is discouraged, and
instead you are encouraged to use what is (claimed to be) a very quick and
easy and painless process of registering "vnd." types. So I'd encourage
LC to investigate doing that for MARC, while waiting for someone to have
time to do an actual (more time consuming) application/marc+xml
registration. That would give us the beneift of an actual registration
(albeit under vnc.) instead of an unregistered x-.
As far as text/xml, the general consensus on the internet seems to be that
it was a mistake, but it's there and no one cares enough to try to somehow
remove it, so it _is_ legal, but nobody really encourages using it. One
problem with text/html is that it's default char encoding is ascii, while
the default char encoding for XML is of course UTF-8. This can very easily
lead to confusion and encoding errors unless software is more careful than
we know most software has a tendency to be. :) Still, it's legal, but I
don't see any reason to encourage it's use for MARC.
application/xml, sure, but it would be _really_ useful, for the reasons
discussed in last week's thread, to have a specific type for marc xml (and
mods). If the folks at LC don't understand why, thinking that
application/xml is sufficient, i could try to write up a persuasive essay
again, or copy and paste from last week's thread. Or is there someone else
other than LC who could conceivably fill out an application for
application/marc+xml and application/mods_xml?
Seriously, application/xml is not sufficient, although it is legal.
Jonathan
Alexander Johannesen wrote:
On Thu, Feb 12, 2009 at 22:32, Jonathan Rochkind <[email protected]>
wrote:
Didn't we finish having this conversation last week? We talked about all
this stuff being brought up now last week.
We did indeed, and your summary is better than what my retort could
have been; spot on.
I guess it's hard to understand why text/xml is such a waste of MIME
and time as long as we still got text/html as the original understood
MIME for HTML pages, but luckily the internet has moved on and
evolved. :)
One question we haven't asked is if we really need a MIME type for
MARCXML. :)
Alex
--
---------------------------------------------------------------------------
Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic
Maps
------------------------------------------
http://shelter.nu/blog/ --------
