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