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 14:17:29 UTC