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