[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 8.3.4: comma separated?! app:accept
- To: Elliotte Harold <elharo@xxxxxxxxxxxxxxx>
- Subject: Re: 8.3.4: comma separated?! app:accept
- From: James M Snell <jasnell@xxxxxxxxx>
- Date: Sat, 10 Mar 2007 08:35:21 -0800
- Cc: Atom-Protocol Protocol <atom-protocol@xxxxxxx>
- Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=FsrTNZkxOX8bCg8pxflaCIAmZJbEXtj8GAHHVfeAFiD/qMYUmb1jwlIyiMJ8XQn4SaiuEUhAyVgr0Cn5RByfqsHdmjdY05OIS1K2qBDJ/hHgXmhMD4bRkaBYnpPWJnzmBeu5rKotT5wZ7YcQMHZrKCrPZq9hk8cFTuyeztlX79w=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=PyH6VfimMBo4DkPL42/oPNdxcXnl62v4WmpZWVe5GOF9K6QDu6T0OdVOOz1Z+eNDLwuog4rmLlyGZET9dBs0hFIgnYJ8K41lAWvSj7h79yEdpCovlWL4keBSYPaI6J3S62N8M0Aey/iW6ErR+j3jHEKN3eKfUNJRGKoJRV/TNFo=
- In-reply-to: <45F2D68B.6050002@xxxxxxxxxxxxxxx>
- List-archive: <http://www.imc.org/atom-protocol/mail-archive/>
- List-id: <atom-protocol.imc.org>
- List-unsubscribe: <mailto:atom-protocol-request@imc.org?body=unsubscribe>
- References: <45F2D68B.6050002@xxxxxxxxxxxxxxx>
- Sender: owner-atom-protocol@xxxxxxxxxxxx
- User-agent: Thunderbird 1.5.0.10 (X11/20070306)
-1. A comma separated list is sufficient.
- James
Elliotte Harold wrote:
>
> Section 8.3.4 states:
>
> 8.3.4 The "app:accept" Element
>
> The "app:accept" element value specifies a comma-separated list of
> media-ranges (see [RFC2616]).
>
> Examples include:
>
>
> <app:accept>image/png,image/*</app:accept>
> <app:accept>image/*, image/png</app:accept>
> <app:accept> image/* </app:accept>
>
> This sets my teeth on edge. Why have we allowed *commas* to intrude into
> our clean XML markup? I'm guessing this just mirrors the HTTP headers,
> but they can't use XML. Furthermore because "app:accept has no notion of
> preference. As a result, the value syntax of app:accept does not use
> 'accept-params' or 'q' arguments as specified in [RFC2616], section
> 14.1." we can't naively copy from one to the other.
>
> I propose allowing multiple app:accept elements, rather than just a
> single one. each app:accept element would contain exactly one media
> type. This would mean in 8.3.3 we change
>
>
> appCollection =
> element app:collection {
> appCommonAttributes,
> attribute href { atomURI },
> ( atomTitle
> & appAccept?
> & appCategories*
> & extensionSansTitleElement* )
> }
>
>
> to
>
>
> appCollection =
> element app:collection {
> appCommonAttributes,
> attribute href { atomURI },
> ( atomTitle
> & appAccept*
> & appCategories*
> & extensionSansTitleElement* )
> }
>
> We'd also need to change the RELAX NG declaration regex of appAccept in
> 8.3.4.
>