Re: Message Reference, Message|element encore

I think that mime type is generally enough when you are dealing with 
binary mime types such as images, but this is not really the case for 
textual mime types.
Taking the xhtml example, you have two DTDs for strict or transitional 
XHTML. It would be good in that case if the WSDL description could give 
the mime type plus some more precise data constraints like XML-Schema 
constraints on simple content, DTDs, regular expressions..., all things 
that fit well in the WSDL schema section. In the.NET HTTP extension 
example you gave, wouldn't the regular expressions be better placed in 
the WSDL schema section?

Also to be noted that we can today describe operations using messages 
consisting in XHTML or SVG documents. Using the HTTP binding, these 
messages will have the "application/xml" mime type while it would be 
more appropriate to use more precise mime types ("application/xhtml+xml" 
or "image/svg+xml" for instance).Therefore, it might be good to be able 
to set the mime type to use for a given message, at least at the HTTP 
binding level, is'nt it ?

There might also be connections between this issue and the media-type 
task force proposal, which allows defining media-type information within 
a schema.
    Youenn

paul.downey@bt.com wrote:

>Youenn
>
>do you think the mime type would be enough information to describe the 
>contents of the messages exchanged ?
>
>e.g. text/plain might cover comma-separated-value (CSV) 
>which then encompasses a myriad of sub-formats, so maybe you'd need
>to have a text/my-flavour-of-csv mime type ?
>
>Or would this entail something akin to the .NET HTTP binding extension 
>which allows parsing of text based on regular expressions, e.g.:
>
>   <binding name="HttpGetBinding" 
>          type="tns:HttpGetType">
>    <http:binding verb="GET"/>
>    <operation name="getDocumentTitle">
>      <http:operation location="index.html"/>
>      <input>
>        <http:urlEncoded/>
>      </input>
>      <output>
>         <text xmlns="http://microsoft.com/wsdl/mime/textMatching/">
>          <match name='Title' pattern='TITLE&gt;(.*?)&lt;'/>
>          <match name='Heading' pattern='H1&gt;(.*?)&lt;'/>
>         </text>
>      </output>
>    </operation>
>  </binding>
>
>Paul
>
>
>-----Original Message-----
>From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
>Behalf Of FABLET Youenn
>Sent: 19 February 2004 10:23
>To: Bijan Parsia
>Cc: www-ws-desc@w3.org
>Subject: Re: Message Reference, Message|element encore
>
>
>
>As suggested by Bijan, there are many HTTP messages exchanged on the web 
>that have simple types data in them, for instace text/plain messages. 
>This leads to some questions:
>    1) Do we want to allow WSDL to describe non-xml message exchanges?
>    2) If yes, do we want to support the description of non-xml message 
>exchanges within the HTTP binding?
>If so, there might be a need to retrieve from a WSDL description the 
>mime type of a particular wsdl message, either at the abstract or 
>concrete level. WSDL cannot describe non-xml HTTP exchanges with the 
>current HTTP binding because the content-type of HTTP requests and 
>responses is currently specified statically in the HTTP binding spec.
>    Youenn
>
>Bijan Parsia wrote:
>
>  
>
>>So, mulling over section 2.4  
>>(http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/ 
>>wsdl20.html#MessageReference) yet again:
>>
>>1) At the F2F, did we agree to change the name of the component  
>>property {message} to "element", or only the attribute?
>>2) At the F2F, Roberto (I believe) assuaged my worries by pointing to  
>>the mapping in 2.4.3:
>>    """{message}     The element declaration resolved to by the value 
>>of the  message attribute information item if present, otherwise a 
>>similar  construct in some type system as referred to by some other 
>>attribute  information item if present, otherwise empty."""
>>
>>    This suggests that the {message} *component* can refer to types 
>>in  arbitrary type systems. However:
>>    a) The text in 2.4.1 reads:
>>    """ {message} A reference to an XML element declaration. This 
>>element  represents the content or "payload" of     the message"""
>>    Which pretty much *states* that the value of a {message} 
>>component  property is an element declaration     *only*. This seems 
>>to be a tension  in the text.
>>    b) I don't see any way to tell *which* type system the {message}  
>>component property refers too
>>3) In section 3.1.3:
>> """A named, global xs:element declaration may be referenced from the  
>>message attribute information item of an input or output element  
>>information item. The QName is constructed from the targetNamespace 
>>of  the schema and the content of the name attribute information item 
>>of  the xs:element element information item. A message attribute  
>>information item may not refer to an xs:simpleType or an 
>>xs:complexType  element information item."""
>>
>>I don't understand why there is a restriction against referencing  
>>xs:simpleTypes. It seems to me that there are plenty of messages 
>>(HTTP  reponses with text/plain bodies?) that are properly described 
>>by  xs:simpleTypes (maybe UPnP as well?) If at all possible, I'd like 
>>to  see the restriction removed.
>>All this suggests (to me) that having to add an attribute for each 
>>type  system is, well, annoying :) Why not have a pair of component  
>>properties, {typeSystem} and {type}. And better, let there be two  
>>attributes in the XML as well. For XML Schema element declarations, 
>>we  can make that omitting the type system attribute defaulst to XML 
>>Schema  element declarations.
>>
>>Cheers,
>>Bijan Parsia.
>>
>>    
>>
>
>  
>