RE: Comments on http://www.w3.org/TR/2004/WD-xml-media-types-20041102/

The simple use case is for a Web service to communicate to the client as
accurately as possible the message structure it expects.  It would be
nice for the description to be able to say things like:
- send me a SOAP envelope (WSDL SOAP binding tells how to do that)
- make the body look like this (XML Schema element declaration tells how
to do that)
- embed your encoded binary data here within that structure (XML Schema
xs:base64Binary datatype tells you where the binary data goes)
- and only embed binary data of the types image/jpeg or image/png -
don't bother sending me an image/gif because I won't be able to process
it (xmime:expectedMediaType adds this additional layer of description).

The last bit is currently described in english or some out of band
mechanism.  Xmime:expectedMediaType provides a common machine-readable
description of this information.  The client can use this description to
construct the message, right down to indicating (with xmime:contentType)
that it chose image/png over image/jpeg.

Which part of this troubles you?

> -----Original Message-----
> From: Larry Masinter [mailto:LMM@acm.org]
> Sent: Friday, February 25, 2005 1:16 PM
> To: Jonathan Marsh; public-ws-media-types@w3.org
> Cc: 'Jon Ferraiolo'
> Subject: RE: Comments on http://www.w3.org/TR/2004/WD-xml-media-types-
> 20041102/
> 
> > Would you have the same objection if, instead of Accept-headers, we
> > simply provided a list of expected media types, with no parameters
> or
> > wildcards?  E.g. xmime:expectedMediaType="image/jpeg image/gif
> > image/png".  This would address, if I understand it correctly, your
> > concern that wildcards lead to incorrect assumptions about the
> > capabilities of the parties involved.  Namely, "how can you assert
> that
> > you accept image/mynewimagetype when I haven't even invented it
> yet?"
> 
> I wouldn't have the same objections; as far as the second objection,
> the terminology would be a closer match (I think; I'd want to see the
> new draft). (Is it conventional to use singular names '...Type' for
> attribute names that contain multiple values?)
> 
> As far as the first objection, I think by changing
> expectedMediaType to actually be an explicit list of media types
> without wildcards you would remove some causes for errors.
> However, I still can't think of clear use case where
> xmime:expectedMediaType would be useful, even if you change it so that
> it is accurate.
> 
> Larry
> --
> http://larry.masinter.net

Received on Friday, 25 February 2005 22:35:58 UTC