Subject: Re: [CODE4LIB] MIME Type for MARC, Mods, etc.?

From: Rebecca S Guenther <[email-masked]>
Date: Thu, 12 Feb 2009 15:43:21 -0500

MARC was registered a long time ago.
http://www.faqs.org/rfcs/rfc2220.html
Some of the text is a bit dated and could stand some updating.

Patrick is right that an XML schema such as MODS or MARCXML would be text/xml.

Rebecca

Rebecca S. Guenther                                                       
 Senior Networking and Standards Specialist                  
 Network Development and MARC Standards Office     
 Library of Congress   
 101 Independence Ave. SE                                       
 Washington, DC 20540                                                      
 Washington, DC 20540-4402                                          
 (202) 707-5092 (voice)    (202) 707-0115 (FAX)           
 [email-masked]
>>> Patrick Yott <[email-masked]> 02/04/09 10:59 AM >>>
Not sure about the binary MARC, but all flavors of xml should be typed to
either text/xml or application/xml, yes?

patrick

On 2/4/09 10:47 AM, "Jonathan Rochkind" <[email-masked]> wrote:

> I am actually rather shocked that it seems that MARC-XML, MODS,
> MARC21-binary, do not have registered Internet Content Types (aka MIME
> types).
> 
> Am I missing something, or is this really so?
> 
> Anyone know what the process is for registering such?  Anyone want to
> help try to do that? I guess we'd probably have to talk to the standards
> organizations for each of those types, rather than doing it independently?
> 
> Jonathan

---

From: Alexander Johannesen <[email-masked]>
Date: Thu, 12 Feb 2009 21:59:52 +0100

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

Hence, a more correct MIME type for XMLMARC would be
application/marc+xml, although until registered should be
application/x-marc+xml.

Alex
-- 
---------------------------------------------------------------------------
 Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
------------------------------------------ http://shelter.nu/blog/ --------

---

From: "Houghton,Andrew" <[email-masked]>
Date: Thu, 12 Feb 2009 16:12:53 -0500

> From: Code for Libraries [mailto:[email-masked]] On Behalf Of
> Alexander Johannesen
> Sent: Thursday, February 12, 2009 4:00 PM
> To: [email-masked]
> Subject: Re: [CODE4LIB] MIME Type for MARC, Mods, etc.?
> 

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.

> application/marc+xml, although until registered should be

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.

---

From: Jonathan Rochkind <[email-masked]>
Date: Thu, 12 Feb 2009 16:32:54 -0500

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:
>>> Patrick is right that an XML schema such as MODS or MARCXML would be
>>>       
>> text/xml.
>>

---

From: Alexander Johannesen <[email-masked]>
Date: Thu, 12 Feb 2009 23:05:04 +0100

> 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
------------------------------------------ http://shelter.nu/blog/ --------

---

From: Jonathan Rochkind <[email-masked]>
Date: Thu, 12 Feb 2009 17:21:51 -0500

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

---

From: Jonathan Rochkind <[email-masked]>
Date: Thu, 12 Feb 2009 17:28:17 -0500

> One question we haven't asked is if we really need a MIME type for MARCXML. :)

PPS: Yes, it has been asked, and it's pretty obvious to me that we do.

Because I write lots of software that will be fetching MARCXML from the 
web, and needs to know what it's got. Much of this software is capable 
of fetching information in many formats, or even arbitrarily in any 
format, which doesn't mean it'll know what to _do_ with any arbitrary 
format.  It needs to identify the content type and decide if it knows 
what to do with it. [One example is OpenURL rft_ref].

If you start to come up with reasons why you don't need an Internet 
Content Type (nee MIME Type) to identify what arbitrary content is, then 
please see the Appendix A  to RFC 3023, where they provide easily 
readable and compelling arguments for why a Content Type makes this 
_much_ more convenient, reliable, and efficient.  As someone 
contemplating writing such software, I agree with their arguments. 

Jonathan

---

From: "Ray Denenberg, Library of Congress" <[email-masked]>
Date: Thu, 12 Feb 2009 17:47:52 -0500

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-masked]>
To: <[email-masked]>
Sent: Thursday, February 12, 2009 5:21 PM
Subject: Re: [CODE4LIB] MIME Type for MARC, Mods, etc.?

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

---

From: Alexander Johannesen <[email-masked]>
Date: Fri, 13 Feb 2009 13:25:41 +0100

> PPS: Yes, it has been asked, and it's pretty obvious to me that we do.

I wasn't asking for technical reasons; I was more having a stab at how
many people use and need MARCXML specifically as compared to a number
of other more used formats. I mean, seriously, you can use MARCXML
embedded in Atom and get the best of both worlds instead.

Don't worry about it; it's not a serious _enough_ question. :)

Alex
------------------------------------------ http://shelter.nu/blog/ --------

---

From: Ross Singer <[email-masked]>
Date: Fri, 13 Feb 2009 10:01:13 -0500

> embedded in Atom and get the best of both worlds instead.

You could, and we do (http://jangle.org/) and it would be immensely
helpful to put it in:

<content type="application/marcxml+xml"><record>...</record></content>

rather than:
<content type="application/xml"><record>...</record></content>

to know that's what's being transported (without having to know
Jangle's extensions).

-Ross.

---

From: "Houghton,Andrew" <[email-masked]>
Date: Fri, 13 Feb 2009 11:07:23 -0500

> Ray Denenberg, Library of Congress
> Sent: Thursday, February 12, 2009 5:48 PM

Please don't forget to also register application/mads+xml too, for those of us who are using MADS.

Andy.

---

From: Jonathan Rochkind <[email-masked]>
Date: Fri, 13 Feb 2009 12:02:26 -0500

Thanks Ray. marcxml+xml makes sense to me, the name is really arbitrary, 
so long as we have _something_ that represents MARC-XML.  Glad you are 
working on this.

I'm confused about your suggestion of registering a content type for 
SRU.  My understanding is that SRU is a _protocol_, not a media type?  
Unless you mean registering a type for the SRU explain document?  In 
general, with my understanding of SRU and of the purpose of internet 
content types, it doesn't seem to make sense to me to register a content 
type for SRU the protocol.

"Media types must function as an actual media format: Registration of 
things that are better thought of as a transfer encoding, as a character 
set, or as a collection of separate entities of another type, is not 
allowed."

Is SRU a media/document type, or is it a communications protocol using a 
collection of separate document types?

Jonathan

---

From: "Houghton,Andrew" <[email-masked]>
Date: Fri, 13 Feb 2009 13:00:40 -0500

> Jonathan Rochkind
> Sent: Friday, February 13, 2009 12:02 PM

SRU is a messaging protocol just like SOAP and HTTP.  When SRU and SOAP
are tunneled through HTTP you are sending back the SRU "message" as the
HTTP entity representation which contains a result set from the search.
You can register protocol messages with IANA, e.g., application/soap+xml
and message/http.

Andy.

---

From: "Ray Denenberg, Library of Congress" <[email-masked]>
Date: Fri, 13 Feb 2009 13:47:05 -0500

Sorry for the confusion over SRU, and I'm afraid this takes up way 
off-topic, but since you asked .....

I meant the SRU *response format*.  And even that doesn't make sense, not in 
the context of the current SRU spec.  But in the next version, 2.0, which we 
are now developing within OASIS, the response can take on different formats, 
subject (possibly) to content negotiation.  For example the response can be 
packaged in ATOM, or RSS, or the default SRU schema, and it is the later 
that we are registering.   --Ray

----- Original Message ----- 
From: "Jonathan Rochkind" <[email-masked]>
To: <[email-masked]>
Sent: Friday, February 13, 2009 12:02 PM
Subject: Re: [CODE4LIB] MIME Type for MARC, Mods, etc.?

> I'm confused about your suggestion of registering a content type for SRU. 
> My understanding is that SRU is a _protocol_, not a media type?  Unless 
> you mean registering a type for the SRU explain document?  In general, 
> with my understanding of SRU and of the purpose of internet content types, 
> it doesn't seem to make sense to me to register a content type for SRU the 
> protocol.
>
>>> and
>>> that
>>> (and
>>> essay