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/2004Nov/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 Thursday, 2 December 2004 19:33:53 UTC