Issue 260 Some alternatives

This issue [1] states a desire to allow expectedMediaType content to
specify any XML document. 

We understand that there is no explicit grouping mechanism for
designating "xml" documents as there are many media types that indicate
xml content. Currently the only way to designate such a grouping is to
provide an explicit list of media range as part of the value of
expectedMediaType attribute, separated with commas. 

The issue is written to suggest our specification should come up with a
special naming to designate any media type that designates xml content
in the spec. The issue is also written to question why we are
disallowing accept-extensions as part of the value of the attribute as
stated by Section 2.2[2]. 

We evaluated the issue. Here are the possible choices: 

(1) do nothing. This will continue to force the user to list media range
that designate xml documents. This option does not introduce any new
design constraints that goes beyond RFC2616 and allow the current
mechanisms to be used as is. 

(2) remove the restriction to allow accept-extensions. In this manner,
extensions may be used to designate groupings, including xml. 

(3) define a special "type" to designate any XML that spans all known
media types that designate xml content. 

We are inclined to think that this wg should not be coming up with a
special name to designate any xml. This is because a similar argument
may be made for providing a grouping mechanism for arbitrary media types
that an application can utilize them with a single name. Therefore, it
appears out of scope to us, so we don't favor option 3. 

If the wg decides to address this issue, we prefer (2) to remove the
restriction to allow accept-extensions. 

Cheers, 

--umit


[1]
http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/issues/wsd-issues-c
ondensed.html#x260
[2] http://www.w3.org/TR/xml-media-types/

Received on Wednesday, 5 January 2005 22:21:08 UTC