Didn't we finish having this conversation last week? We talked about all
this stuff being brought up now last week.

Andrew, for why marc+xml is appropriate, see RFC 3023.

I am completely confident that application/marc+xml would be the right
type to register for (eg) MARC XML , and that until it is registered
application/x-marc+xml is appropriate. (I think it would actually be
useful if LC published some guidance suggesting using
application/x-marc+xml and application/x-mods+xml etc, until they are
registered officially, which really ought to be done soon).

There is no formal tie between application/marc and (hypothetically
registered) application/marc+xml, they are completely seperate
registrations--registering an application/marc+xml actually has nothing
to do with the application/marc registration. See RFC 3023.
We _could_ call a MARC-xml registration "application/lcmarc+xml" or
something, it would just be confusing. Of course there are more than
one hypothetical way to serialize MARC as XML -- that's why you do an
IANA registration, to specify which one you mean. (And if you needed to
register a second one, you could use application/marc-other+xml or
something). Of course, in reality, there's only one XML serialization
of MARC anyone uses.

"+xml" has nothing to do with "allowing namespace extensions", except in
the sense that all theoretically does XML does. +xml is a hint that the
content type registered is a particular XML application. If that
application's schema or spec does not allow inclusion of arbitrary
namespaced XML, that's got nothing to do with an +xml content type.
Again, see RFC 3023.

application/xml or text/xml would also be legal, although not nearly as
useful. text/xml should only be used if you want user agents who don't
'know' xml to degrade to displaying the source (xml tags at all)
essentially as text/plain. Which is a question that doesn't really come
up much realistically, but all contemporary RFCs on XML and internet
content types advise against using text/xml except in vary specific
circumstances--although it IS legal. application/xml is also of course
legal, but not nearly as useful as a specific registered type like
application/marc+xml. Any modern user agent knows to degrade
"application/*+xml" to being treated like "application/xml", if the user
agent doesn't know the specific type.

Jonathan

Houghton,Andrew wrote:
>> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
>> Alexander Johannesen
>> Sent: Thursday, February 12, 2009 4:00 PM
>> To: [log in to unmask]
>> Subject: Re: [CODE4LIB] MIME Type for MARC, Mods, etc.?
>>
>> On Thu, Feb 12, 2009 at 21:43, Rebecca S Guenther <[log in to unmask]> wrote:
>>
>>> Patrick is right that an XML schema such as MODS or MARCXML would be
>>>
>> text/xml.
>>
>> I would strongly advise against text/xml, as it is an oxymoron (text
>> is not XML XML is not text even if it is delivered through a text
>> protocol), and more and more are switching away from the generic text
>> protocol (which makes little sense in structured data).
>>
>
> According to RFC 3023, section 3 XML Media Types:
>
> If an XML document -- that is, the unprocessed, source XML document
> -- is readable by casual users, text/xml is preferable to
> application/xml. MIME user agents (and web user agents) that do not
> have explicit support for text/xml will treat it as text/plain, for
> example, by displaying the XML MIME entity as plain text.
> Application/xml is preferable when the XML MIME entity is unreadable
> by casual users.
>
> So it is justified to return a Content-Type header with text/xml. It
> depends upon whether you think MARC-XML, MODS, MADS, etc. are readable
> by casual users and the user agents you expect to be accessing the
> documents.
>
>
>> Hence, a more correct MIME type for XMLMARC would be
>> application/marc+xml, although until registered should be
>> application/x-marc+xml.
>>
>
> I'm not sure the +xml is correct on two fronts. First RFC 2220 defines
> the media type for MARC binary, not MARC-XML, and it was my understanding
> that the +xml meant that the schema allowed extension by using XML
> namespaces which MARC binary does not. Further, in the case of MARC-XML,
> its schema also does not allow arbitrary XML elements. MODS and MADS I
> believe do, but that is a different story.
>
>
> Andy.
>
>