"Content type" and "media type"

[MURATA Makoto]

2014-08-09 7:22 GMT+09:00 John Haug <johnhaug at exchange.microsoft.com>:
> I think Caroline raises well-considered points and I tend to agree with her
> assessment.

Agreed.  Let's discuss in the next teleconf.

>
> I don’t think we discussed this topic on the previous call, so I may not yet
> have shared this info.  Previously, someone asked why OPC’s content type
> allows an empty string (RFC 2616 does not allow this for media-type).  Some
> package parts are files with known types, others may be serialized bits with
> no or no known types.  The designer told me it was a tradeoff decision to
> avoid having to guess or fake a type.

The same thing applies to web servers.  They use application/octet-stream
rather than the empty string.

Regards,
Makoto

>
>
>
> John
>
>
>
> From: Arms, Caroline [mailto:caar at loc.gov]
> Sent: Thursday, July 17, 2014 8:05 AM
> To: 'e-SC34-WG4 at ecma-international.org'
> Subject: "Content type" and "media type"
>
>
>
> All,
>
>
>
> Here is the message, I promised to send to the list on today’s call.
>
>
>
> After the earlier call where John reported on his action item asking the
> folks who designed and documented OPC about their use of “content type” and
> “media type,”  I was motivated to look at RFC 2616 and Part 2 in a bit more
> detail, in part to try and understand Murata-san’s underlying concern.
>
>
>
> The explanation John reported is consistent with how I have interpreted the
> phrase in Part 2 (OPC).  John indicated that the OPC designers saw  “content
> type” as an abstract concept.  To me that makes sense, since there are lots
> of typologies for "content" used in different contexts.  In OPC,
> "media-type" as defined in the RFC is the particular syntactic
> representation used to identify types of content.   I see a value in having
> two terms, one for the concept and the other for the particular syntax and
> instances thereof.  I do not believe that Part 2 gets the usage of the terms
> quite straight and do think that the definition of "content type" needs
> adjustment, particularly after the WD0 adjustment in line with ISO
> guidelines.  [Aside: I don't think RFC 2616 gets its term usage quite
> consistent either.]
>
>
>
> Comparing OPC and RFC 2616:
>
>
>
> Each has a data structure with a name based on the words "content" and
> "type." Both structures incorporate values that follow the media-type
> syntax.
>
>
>
> OPC has the Content Types stream  (defined in 9.2.3.3 in Rex's base WD0 doc)
> which makes use of a ContentType attribute which takes values that follow
> the media-type syntax.
>
>
>
> RFC 2616 defines a Content-Type entity-header field by:
>
>    Content-Type   = "Content-Type" ":" media-type
>
>
>
> === My personal views ===
>
> 1.  We need the two terms but need to review Part 2 carefully for
> appropriate usage of the terms.  For example, "A content type as defined in
> RFC 2616." in annotations in the tables in 9.2.3.3.3 and 9.2.3.3.4 seems
> wrong, since we do not use the Content-Type structure defined in RFC 2616
> (see above).
>
>
>
> 2.  Personally, I have always found the use of "media" in media-type a
> perplexing use of the word.  I would never use the word "media" to replace
> "content."  They are not synonyms.
>
>
>
> 3.  We should avoid major changes in terminology because several formats
> based on OPC have documentation that makes substantial use of "content type"
> as a phrase.  Indeed, ECMA 388 (XPS spec.) does not appear to use
> "media-type" or "media type," only "content type."
>
>
>
> Other examples from documentation for OPC-based formats:
>
> "The part's content type property uses a MIME-style media type to describe
> part content."
>
> "Content Type Component: XML markup (stored in a ZIP item) that identifies
> the MIME Media Type of each Part in the Package."
>
>
>
> 4.  The fact that OPC allows "parameters" in the media-type syntax to be
> disallowed (and XPS does disallow them) seems like another reason to keep
> the terms distinct.
>
> = = =
>
>
>
> If others agree in general, I am prepared (at some convenient future point)
> to do a careful read of Part 2 with this particular issue in mind and
> propose changes.
>
>
>
>     Caroline
>
>



-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto