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.
>
>