Re: expectedMediaType and Accept header syntax (was Re: Action it em: HTTP binding for accepts header and output Serialization.)

* Umit Yalcinalp <umit.yalcinalp@oracle.com> [2004-06-24 09:54-0700]
> >>Actually, we may want to regard this as a bug: 
> >>it is desirable to have a syntax for expectedMediaType 
> >>compatible with the HTTP Accept header syntax.
> >>   
> >>
> >
> >+1 to consider that as a bug (see [1]). According to prose  [2], "The type
> >of the expectedMediaType element information item is xs:string. The value 
> >of
> >the expectedMediaType element is similar to the value allowed for the
> >'Accept' header defined by HTTP 1.1 specification, Section 14.1 [IETF RFC
> >2616]."
> > 
> >
> Yes, it is a bug as the intent is clear.

The following is a new definition for expectedMediaType. Here are the
changes I have made:
- added support for */*;
- added support for quality factor, e.g. image/png;q=0.8;
- added comma-separated syntax, e.g image/png;q=0.8, image/gif;q=0.1.

  <xs:element name="expectedMediaType" >
    <xs:simpleType>
      <xs:restriction base="xs:string" >
 <xs:pattern value="(\*/\*|(text|application|image|audio|video|model|x-[-.a-z0-9]+)/(([a-z0-9][-.+a-z0-9]+)|\*))(; *q=([01](\.[0-9]{1,3})?|\*))?(, *(\*/\*|(text|application|image|audio|video|model|x-[-.a-z0-9]+)/(([a-z0-9][-.+a-z0-9]+)|\*))(; *q=([01](\.[0-9]{1,3})?|\*))?)*" />
      </xs:restriction>
    </xs:simpleType>
  </xs:element>

I am afraid that the resulting regular expression is hairy, and even
though it is, there is still one thing missing:

  accept-extension = ";" token [ "=" ( token | quoted-string ) ]

for:

  accept-params  = ";" "q" "=" qvalue *( accept-extension )

I didn't add it as I getting HTTP/1.1 tokens in there is going to take
it one level further in terms of uglyness, that I wasn't ready to
reach yet. To have an idea of what it would look like, I had defined
an http11token type in [3].

I am worried that this is going to make the regular expression and the
type definition obscure, so I am starting to wonder if we shouldn't
just refer to section 14.1 Accept of RFC 2616.

One problems that was brought to my attention as we move away from an
<xsd:list/> and use a regular expressing for separating the values
with commas is that queries on media types are likely to be more
complex.

So, in the end, I'll venture the following proposal: define
expectedMediaTypeItem as "media-range [ accept-params ]" as defined in
section 14.1 Accept of RFC 2616 — that we can translate into an
xsd:string restriction if we want, and define expectedMediaType as a
list of expectedMediaTypeItem, saying that it's an XML representation
of the HTTP/1.1 Accept header and define a simple mapping from the
space-separated XML representation to the comma-separated HTTP/1.1
header representation.

Regards,

Hugo

  3. http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0057.html
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/