RE: Media Types LC Issues

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 15:18:26 UTC