RE: Media Types LC Issues

Thanks Kevin. I forgot to include this into the list. 

This should be called Issue MTLC20.  

I will send a possible categorization, as some of the issues in the list
are of editorial in nature and some of the issues require wg discussion
to resolve. Anish and I can knock down the editorial ones relatively
quickly. 

--umit

>-----Original Message-----
>From: Liu, Kevin 
>Sent: Thursday, Dec 02, 2004 20:52 PM
>To: 'Anish Karmarkar'; Anish Karmarkar
>Cc: Yalcinalp, Umit; David Booth; www-ws-desc@w3.org; Jonathan Marsh
>Subject: RE: Media Types LC Issues
>
>
>Hi Anish,
>
>Another comment. 
>
>We added the constructs xmlmime:base64binary and 
>xml:mime:hexBinary for convient use. But the current draft is 
>not very clear how they should be used. It would be nice if 
>their use can be demoed in at least one of the examples. 
>
>Here is my suggestion. Change the following
>
>"
>For authoring convenience, two types xmlmime:base64Binary and 
>xmlmime:hexBinary are defined in B Appendix Schema
>
>Example 1: Element with binary content and contentType attribute
>
><?xml version="1.0" ?>
><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>           xmlns:tns="http://example.com/ct-required"
>           xmlns:xmlmime="http://www.w3.org/2004/10/xmlmime"
>           targetNamespace="http://example.com/ct-required">
>
>    <xs:import namespace="http://www.w3.org/2004/10/xmlmime"
>            schemaLocation="http://www.w3.org/2004/10/xmlmime"/>
>
>    <!-- This element has binary content and requires the contentType
>         attribute that indicates the media type of the binary 
>content -->
>    <xs:element name="MyBinaryData"/>
>      <xs:complexType>
>        <xs:simpleContent>
>          <xs:restriction base="xs:base64Binary" >
>            <xs:attribute ref="xmlmime:contentType" use="required"/>
>          </xs:restriction>
>        </xs:simpleContent>
>      </xs:complexType>
>    </xs:element>
>
></xs:schema>
>"
>
>TO: 
>
>"
>Example 1: Element with binary content and contentType attribute
>
><?xml version="1.0" ?>
><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>           xmlns:tns="http://example.com/ct-required"
>           xmlns:xmlmime="http://www.w3.org/2004/10/xmlmime"
>           targetNamespace="http://example.com/ct-required">
>
>    <xs:import namespace="http://www.w3.org/2004/10/xmlmime"
>            schemaLocation="http://www.w3.org/2004/10/xmlmime"/>
>
>    <!-- This element has binary content and requires the contentType
>         attribute that indicates the media type of the binary 
>content -->
>    <xs:element name="MyBinaryData"/>
>      <xs:complexType>
>        <xs:simpleContent>
>          <xs:restriction base="xs:base64Binary" >
>            <xs:attribute ref="xmlmime:contentType" use="required"/>
>          </xs:restriction>
>        </xs:simpleContent>
>      </xs:complexType>
>    </xs:element>
>
></xs:schema>
>
>For authoring convenience, two types xmlmime:base64Binary and 
>xmlmime:hexBinary are defined in B Appendix Schema. So 
>alternatively, the above example can also be defined as:  
>
><?xml version="1.0" ?>
><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>           xmlns:tns="http://example.com/ct-required"
>           xmlns:xmlmime="http://www.w3.org/2004/10/xmlmime"
>           targetNamespace="http://example.com/ct-required">
>
>    <xs:import namespace="http://www.w3.org/2004/10/xmlmime"
>            schemaLocation="http://www.w3.org/2004/10/xmlmime"/>
>
>    <!-- This element has binary content and requires the contentType
>         attribute that indicates the media type of the binary 
>content -->
>    <xs:element name="MyBinaryData" type = "xmlmime:base64Binary"/>
>
></xs:schema>
>"
>
>I briefly mentioned this to Umit before. Just send it to the 
>list for the record.
>
>Best Regards,
>Kevin
> 
>
>>-----Original Message-----
>>From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] 
>>Sent: Thursday, Dec 02, 2004 11:33 AM
>>To: Jonathan Marsh
>>Cc: Yalcinalp, Umit; David Booth; www-ws-desc@w3.org
>>Subject: Re: Media Types LC Issues
>>
>>
>>
>>Please note that there was another email [1] (contain 
>feedback/issues) 
>>sent to the public-ws-media-types list after Umit and I went 
>>through all 
>>the emails. [1] is not included in the list that Umit sent out.
>>
>>-Anish
>>--
>>
>>[1] 
>>http://lists.w3.org/Archives/Public/public-ws-media-types/2004N
>>ov/0011.html
>>
>>Jonathan Marsh wrote:
>>
>>> Yes, that task has been on my to-do list for a few weeks 
>>now, and I just
>>> haven't gotten to it yet...
>>> 
>>> 
>>>>-----Original Message-----
>>>>From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
>>>>On Behalf Of Yalcinalp, Umit
>>>>Sent: Thursday, December 02, 2004 6:17 AM
>>>>To: David Booth
>>>>Cc: www-ws-desc@w3.org
>>>>Subject: Media Types LC Issues
>>>>
>>>>
>>>>All,
>>>>
>>>>Dear All,
>>>>
>>>>Anish and I got together and identified the following 19 LC issues
>>>>posted in the media types public list. Please find them in 
>>this email.
>>>>
>>>>Jonathan, is it possible to convert them to actual issues so 
>>that they
>>>>are tracked formally.
>>>>
>>>>Cheers,
>>>>
>>>>-- umit
>>>>
>>>>------------------------------------------------------
>>>>
>>>>
>>>>
>>>>MTLC1) Normative/informative reference [1]
>>>>
>>>>Raised by Bjoern Hoehrmann on 2nd nov, 2004
>>>>
>>>>"Please change the document so that it is clear which sections and
>>>>which
>>>>references are normative and which are informative."
>>>>
>>>>MTLC2) Editorial Note uses table markup but no tabular data [1]
>>>>
>>>>Raised by Bjoern Hoehrmann on 2nd nov, 2004
>>>>
>>>>"The document has several sections labeled "Editorial note", 
>>these use
>>>>table markup but do not really contain tabular data, please 
>>change the
>>>>markup to something else, e.g. <dl> or just a <p> with a <strong>
>>>>leading "Editorial note:". Also note that "Editorial note:" is not a
>>>>proper table summary (as specified in the summary attribute)."
>>>>
>>>>
>>>>MTLC3) Update reference to XML Infoset [1]
>>>>
>>>>Raised by Bjoern Hoehrmann on 2nd nov, 2004
>>>>
>>>>"The xml-infoset reference refers to the first edition of the
>>>>document,
>>>>please change it to refer to the second edition."
>>>>
>>>>MTLC4) Remove the use of charset parameter in example containing
>>>>text/xml [1]
>>>>
>>>>Raised by Bjoern Hoehrmann on 2nd nov, 2004
>>>>
>>>>"Section 1 has an example "text/xml; charset=utf-16", please change
>>>>this
>>>>example to something else, use of text/xml is discouraged 
>and for XML
>>>>documents using a charset parameter is claimed to be unnecessary and
>>>>harmful."
>>>>
>>>>MTLC5) Clarify the use of example.org and exampl.com [1]
>>>>
>>>>Raised by Bjoern Hoehrmann on 2nd nov, 2004
>>>>
>>>>"Section 1.1 states
>>>>
>>>>   Namespace names of the general form "http://example.org/..." and
>>>>   "http://example.com/..." represent application or 
>>context-dependent
>>>>   URIs [IETF RFC 2396].
>>>>
>>>>Please clarify in the document what you mean here, the 
>statement does
>>>>not really make sense to me."
>>>>
>>>>MTLC6) Namespace name too long and had dates [1]
>>>>
>>>>Raised by Bjoern Hoehrmann on 2nd nov, 2004
>>>>
>>>>"Section 1.1 notes "http://www.w3.org/2004/11/xmlmime" is defined by
>>>>the
>>>>document, the namespace URI is too long and it generally 
>makes little
>>>>sense to put dates into namespaces URIs, please change this at least
>>>>to
>>>>e.g. "http://www.w3.org/2004/xmlmime" to be consistent with a wide
>>>>range
>>>>of W3C namespaces URIs."
>>>>
>>>>MTLC7) Production rules for expectedMediaType [1]
>>>>
>>>>Raised by Bjoern Hoehrmann on 2nd nov, 2004
>>>>
>>>>"Section 2.2 states
>>>>
>>>>   The value and the meaning of the expectedMediaType attribute is
>>>>   similar to the value allowed for the 'Accept' header defined by
>>>>HTTP
>>>>   1.1 specification, Section 14.1 [IETF RFC 2616] and MUST 
>>follow the
>>>>   production rules defined in that section. The 'q' 
>>parameter defined
>>>>by
>>>>   HTTP 1.1 specification, Section 3.9 [IETF RFC 2616] is 
>>allowed, but
>>>>   other accept-extensions are not allowed.
>>>>
>>>>The production rule in RFC 2616 cannot be used here, it is 
>defined in
>>>>terms of octets while the information item is a sequence of
>>>>characters.
>>>>In order to re-use the production rule you would need to 
>>define how to
>>>>map the characters to octets before attempting to match; the 
>>alternate
>>>>solution would be to create a new production rule that is defined in
>>>>terms of characters.
>>>>
>>>>Please change the section so that it is clear what the differences
>>>>are,
>>>>you note these are "similar" and cite one difference, but it is not
>>>>clear to me whether this is the only difference.
>>>>
>>>>Please change the section so that it is clear which production rule
>>>>you
>>>>actually mean, section 14.1 of RFC 2616 has several. It would seem
>>>>that
>>>>you mean the production rule for "Accept", but as that contains
>>>>"Accept:" you probably don't, so you might mean the Accept 
>production
>>>>rule without the leading "Accept:" or media-range.
>>>>
>>>>Whatever you do, please ensure that parameters can be used, e.g.
>>>>
>>>>   x:expectedMediaType = 'application/xhtml+xml;profile=http://...'
>>>>"
>>>>
>>>>MTLC8) Allow expectedMediaType to specify any XML document [1]
>>>>
>>>>Raised by Bjoern Hoehrmann on 2nd nov, 2004
>>>>
>>>>"It seems that re-using the Accept header syntax here makes it
>>>>impossible
>>>>to state that any kind of "XML" is accepted, I however think 
>>that this
>>>>is an important use case for such an attribute. It is often not
>>>>possible
>>>>to include XML documents in other XML documents (e.g. if 
>the document
>>>>has a document type declaration). Using e.g.
>>>>
>>>>   x:expectedMediaType = 'application/xml'
>>>>
>>>>would likely not work as e.g. image/svg+xml does not match. I think
>>>>the
>>>>syntax should be extended so that it is possible to express that XML
>>>>is
>>>>expected whatever type might be used. This would be useful 
>e.g. for a
>>>>web service interface to the W3C Markup Validator.
>>>>
>>>>The attribute could allow a special string like
>>>>
>>>>   x:expectedMediaType = 'xml'
>>>>
>>>>in place of a media-range, this would allow the W3C Markup Validator
>>>>to
>>>>use it like
>>>>
>>>>   x:expectedMediaType = 'xml, text/html, text/sgml'
>>>>
>>>>If accept-extensions continues to be disallowed, please include a
>>>>rationale for the exclusion in the document."
>>>>
>>>>MTLC9) Allow expecteMediaType to contain '*' [1]
>>>>
>>>>Raised by Bjoern Hoehrmann on 2nd nov, 2004
>>>>
>>>>"Section 3.1 states
>>>>
>>>>   When the expectedMediaType annotation attribute has a wildcard
>>>>("*")
>>>>   or a list of acceptable media types, the schema SHOULD 
>require the
>>>>   contentType attribute to be present.
>>>>
>>>>This seems to imply that
>>>>
>>>>   x:expectedMediaType = '*'
>>>>
>>>>would be allowed which does not seem to be the case. If the 
>intention
>>>>is
>>>>to allow this syntax, please change the definition 
>accordingly, if it
>>>>is
>>>>not allowed, please re-word the paragraph to make it clear what you
>>>>mean."
>>>>
>>>>MTLC10) Value of contentType and the range specified by
>>>>expectedMediaType [1]
>>>>
>>>>Raised by Bjoern Hoehrmann on 2nd nov, 2004
>>>>
>>>>"Section 3.1 states
>>>>
>>>>   The value of the contentType attribute, if present, SHOULD be
>>>>within
>>>>   the range specified by the expectedMediaType annotation 
>attribute,
>>>>if
>>>>   specified in the schema.
>>>>
>>>>It is not clear to me how it is determined whether this requirement
>>>>has
>>>>been met. If there is an algorithm, please reference it normatively,
>>>>or
>>>>provide your own."
>>>>
>>>>MTLC11) Lexical and value space of the attributes and XML 
>schema decl
>>>>[1]
>>>>
>>>>Raised by Bjoern Hoehrmann on 2nd nov, 2004
>>>>
>>>>"Section 2.1 does not define the lexical or value space of the
>>>>attribute,
>>>>it states it is xs:string but it would seem you would rather want to
>>>>say
>>>>that this relates to RFC 2616 Content-Type in some way. When fixing
>>>>this
>>>>please consider my remarks about the "Accept:" header 
>reference here,
>>>>too.
>>>>
>>>>The XML Schema for the attributes seems overly lax, for example, as
>>>>currently defined, x:expectedMediaType requires that the 
>>string has at
>>>>least three characters, please change the definition so that a XML
>>>>Schema Validator can determine conformance of the attribute value as
>>>>much as possible."
>>>>
>>>>MTLC12) Add NS prefix to all occurences of expecteMediaType and
>>>>contentType [1]
>>>>
>>>>Raised by Bjoern Hoehrmann on 2nd nov, 2004
>>>>
>>>>"Please add a namespace prefix to all occurences of
>>>>"expectedMediaType"
>>>>and "contentType" in the document where you do not 
>specifically refer
>>>>to
>>>>the local name of the attribute, this helps to avoid 
>>misunderstandings
>>>>by people not totally namespace-aware and make the document more
>>>>readable."
>>>>
>>>>MTLC13) Update XOP reference [2]
>>>>
>>>>Raised by Klotz Leigh on 3rd nov, 2004
>>>>
>>>>"The reference to XOP in this Working Draft
>>>>http://www.w3.org/TR/2004/WD-xml-media-types-20041102/ is to the
>>>>Working
>>>>Draft revision of XOP at 
>http://www.w3.org/TR/2004/WD-xop10-20040209/
>>>>and
>>>>should be to the CR version http://www.w3.org/TR/2004/CR-xop10-
>>>>20040826/
>>>>as
>>>>it incorporates the xmlmime:contentType attribute defined in this
>>>>Working
>>>>Draft."
>>>>
>>>>MTLC14) How to distinguish between hexBinary and base64Binary in the
>>>>absence
>>>>of XML schema [3]
>>>>
>>>>Raised by John Cowan on 3rd nov, 2004
>>>>
>>>>"The introduction to the 2 November 2004 Last Call WD of "Assigning
>>>>Media
>>>>Types to Binary XML" states that XML Schema is not required in order
>>>>to
>>>>make use of the xmlmime:contentType attribute.
>>>>
>>>>Unfortunately, without type information it is not possible 
>>to reliably
>>>>distinguish between elements with base64 binary and hex binary
>>>>content:
>>>>for example, the content "0000" decodes to the octets "0x00 0x00" in
>>>>hex binary, but "0xD3 0x4D 0x34" in base64 binary.
>>>>
>>>>Therefore, either an xmlmime:contentTransferEncoding is required for
>>>>schema-free operations, or the recommendation should specify the use
>>>>of
>>>>xsi:type with the values "xs:base64Binary" and 
>"xs:hexBinary" for use
>>>>in schema-free operations.
>>>>
>>>>I would prefer the latter alternative."
>>>>
>>>>MTLC15) Bad namespace prefix [4]
>>>>
>>>>Raised by Paul Cotton on 4th nov, 2004
>>>>
>>>>"Table 1. "Prefixes and Namespaces used in this 
>>specification" defines
>>>>the prefix "xmlmime" for the namespace URI
>>>>"http://www.w3.org/2004/11/xmlmime".  This is an invalid namespace
>>>>prefix since a namespace prefix is not allowed to start with the
>>>>reserved string "xml".  See [1]:
>>>>
>>>>===
>>>>Namespace Constraint: Leading "XML"
>>>>Prefixes beginning with the three-letter sequence x, m, l, 
>>in any case
>>>>combination, are reserved for use by XML and XML-related
>>>>specifications.
>>>>===
>>>>"
>>>>
>>>>MTLC16) Interop problems with Accept HTTP header[5]
>>>>
>>>>Raised by Larry Masinter on 4th Nov, 2004
>>>>
>>>>'
>>>>I'm suspicious of the attempt to use HTTP "accept" headers
>>>>to "indicate in XML Schema what media
>>>>    type the character content of an element will have."
>>>>
>>>>In practice, HTTP Accept headers have turned out to have
>>>>severe interoperability problems, and have not been useful
>>>>for content negotiation. It's a bad practice to try to
>>>>follow something that hasn't worked for the stated purpose.
>>>>For example, a description of "image/*" is, in practice,
>>>>not useful because of the wide variety of image types
>>>>that are likely *not* implemented.
>>>>
>>>>In general, indicating ranges of acceptable media type
>>>>is quite difficult; the best practice in this area is
>>>>likely to be either CCPP (www.w3.org/Mobile/CCPP/)
>>>>or media feature expressions (RFC 2533 plus
>>>>RFC 2913). However, neither have widespread deployment
>>>>and interoperability experience.
>>>>'
>>>>
>>>>MTLC17) ContentType of media type [5]
>>>>
>>>>Raised by Larry Masinter on 4th Nov, 2004
>>>>
>>>>'
>>>>I think the document suffers from an editorial
>>>>problem which starts with the title. "text/xml;charset=utf-8"
>>>>is not a "IANA media type" or a "media type token", it
>>>>is a "content-type string", the difference being that
>>>>a content-type string starts with a media type followed
>>>>by parameters for that type.
>>>>
>>>>I think it's important to avoid confusion by careful
>>>>editing:
>>>>
>>>>- The title: "Assigning Media Types to Binary"
>>>>   probably should be "Describing Media Content of Binary"
>>>>
>>>>- The schema definition could be 'expectedContentType'
>>>>   instead of 'expectedContentType' (if a single value;
>>>>   if a more complex type expression language is allowed,
>>>>   then rename accordingly).
>>>>
>>>>- "Declaring media types for binary data"
>>>>   => "Declaring Content-Type for binary data".
>>>>
>>>>- "the name of an IANA media type token" =>
>>>>    "a valid content-type string"
>>>>'
>>>>
>>>>MTLC18) Normalization for content-type strings [5]
>>>>
>>>>Raised by Larry Masinter on 4th Nov, 2004
>>>>
>>>>'
>>>>[normalized value]": I think defining a normalization for
>>>>content-type strings is difficult, and you should avoid it.
>>>>'
>>>>
>>>>MTLC19) Why is contentType attribute required? [6]
>>>>
>>>>Raised by Ian Hickson on 18th nov, 2004
>>>>
>>>>"
>>>>I am confused as to why the mime:contentType attribute is required.
>>>>
>>>>It would seem that applications that expect binary content will have
>>>>to
>>>>be
>>>>hardcoded to support the elements in which that content appears
>>>>anyway,
>>>>so
>>>>supporting an attribute on those elements as well seems like it
>>>>wouldn't
>>>>require the use of namespaces.
>>>>
>>>>As a data point: XLink is used in SVG on elements that refer to
>>>>external
>>>>resources, as in <style xlink:href="">. The theory is that 
>by reusing
>>>>the
>>>>same attribute for all links, the implementation is somehow able to
>>>>reuse
>>>>code. However, in practice, the UAs have to have code for each
>>>>embedding
>>>>mechanism, and the attribute doesn't help at all by being in 
>>the XLink
>>>>namespace.
>>>>
>>>>So while I can understand that XML Schema may need to be extended to
>>>>support MIME types as a first-class data type, it would 
>seem that the
>>>>actual mime:contentType attribute is superfluous.
>>>>"
>>>>
>>>>
>>>>[1]
>>>>http://lists.w3.org/Archives/Public/public-ws-media-
>>>>types/2004Nov/0000.h
>>>>tml
>>>>[2]
>>>>http://lists.w3.org/Archives/Public/public-ws-media-
>>>>types/2004Nov/0001.h
>>>>tml
>>>>[3]
>>>>http://lists.w3.org/Archives/Public/public-ws-media-
>>>>types/2004Nov/0002.h
>>>>tml
>>>>[4]
>>>>http://lists.w3.org/Archives/Public/public-ws-media-
>>>>types/2004Nov/0003.h
>>>>tml
>>>>[5]
>>>>http://lists.w3.org/Archives/Public/public-ws-media-
>>>>types/2004Nov/0006.h
>>>>tml
>>>>[6]
>>>>http://lists.w3.org/Archives/Public/public-ws-media-
>>>>types/2004Nov/0008.h
>>>>tml
>>> 
>>> 
>>> 
>>
>>
>

Received on Friday, 3 December 2004 09:41:28 UTC