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" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Friday, February 13, 2009 12:02 PM
Subject: Re: [CODE4LIB] MIME Type for MARC, Mods, etc.?
> 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
>
> Ray Denenberg, Library of Congress wrote:
>> 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" <[log in to unmask]>
>> To: <[log in to unmask]>
>> 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 <[log in to unmask]>
>>>> 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/ --------
>>>>
>>>>
>>>>
>>
>>
|
