Re: atom:content's src and server-driven content negotiation

2006-01-20 Thread Andreas Sewe
Graham Parks wrote: David Powell wrote: Possibly, but that solution isn't perfect. There is a tradeoff between supplying an inaccurate type, and supplying no type at all. This TAG finding [1] discusses the issue quite thoroughly. [1] http://www.w3.org/2001/tag/doc/mime-respect-20040225

Re: atom:content's src and server-driven content negotiation

2006-01-19 Thread Graham Parks
On 18 Jan 2006, at 12:05 pm, Andreas Sewe wrote: Note, however, that a type attribute on the content element cannot be used since /img is a negotiated resource -- this violates the SHOULD in 4.1.3.2.: 'If the src attribute is present, the type attribute SHOULD be provided [...].' Note

Re: atom:content's src and server-driven content negotiation

2006-01-19 Thread David Powell
Thursday, January 19, 2006, 11:17:38 AM, Graham Parks wrote: The correct thing to do is to pick the one provided by default by the server when no content negotiation occurs. eg: content type=image/png href=http://www.example.com/img; / Possibly, but that solution isn't perfect. There is

Re: atom:content's src and server-driven content negotiation

2006-01-19 Thread Graham Parks
On 19 Jan 2006, at 11:53 am, David Powell wrote: Possibly, but that solution isn't perfect. There is a tradeoff between supplying an inaccurate type, and supplying no type at all. This TAG finding [1] discusses the issue quite thoroughly. [1]

atom:content's src and server-driven content negotiation

2006-01-18 Thread Andreas Sewe
I don't want to start yet another discussion about violating SHOULD level requirements but I can't think of any better way to handle the following situation (but hopefully you can :-): Suppose the host www.example.com uses HTTP/1.1's server-driven content negotiation for its resource /img

Re: atom:content's src and server-driven content negotiation

2006-01-18 Thread John Panzer
Andreas Sewe wrote: I don't want to start yet another discussion about violating SHOULD level requirements but I can't think of any better way to handle the following situation (but hopefully you can :-): Suppose the host www.example.com uses HTTP/1.1's server-driven content negotiation