Re: Content negotiation issues (was XInclude)

ralinon@hotmail.com (Jeremy Dunck) writes:
>" This attribute specifies the content type for the data specified by
>data. This attribute is optional but recommended when data is specified
>since it allows the user agent to avoid loading information for
>unsupported content types. If the value of this attribute differs from
>the HTTP Content-Type returned by the server when the object is
>retrieved, the HTTP Content-Type takes precedence."
>
>My point is that the server -still- maintains control over the actual
>MIME type of representation returned.

So in effect this is an unfortunately weak effort to avoid content-type
problems by giving the author the opportunity to specify alternate URIs
which may reliably be expected to provide an expected answer.  I can see
content negotatiation as one aspect of "allows the user agent to avoid
loading information for unsupported content types" without stretching my
mind particularly far.

>>HTML, SMIL, and SVG, most of the XML-based specifications - including
>>XInclude and XLink - seem to take a "we provide the URI reference, you
>>do with it as you like" approach.
>
>I am not so sure this is a bad way to go.  In my opinion, the server
>must maintain control of the type of the representation returned. 
>However, that doesn't preclude a client from using it in some other
>way 

It seems that you've forgotten that content-negotiation is a
conversation - the client at least has a chance to request a form that
it finds palatable.  It is unfortunate that so many specifications
forget this, and on the XML side quite completely ignore it.

><snip>
>>While these principle don't explicitly reject the more explicit
>>specification approach of HTML etc., the combination of their
>>(generally worthwhile) conservatism and the lack of specification of
>>any explicit mechanisms in the XML specifications to handle
>>content-negotiation should effectively provide a straitjacket for
>>conscientious XML developers.
>
>I'm not sure I followed that.  Is this derived from the
>misunderstanding that the HTML type attribute is used in content
>negotiation?

I believe it's actually derived from frustration with what I see as an
unnecessarliy fatalistic error on the part of specification developers,
who apparently feel that the relationship between resources and
representations should be beyond their control.  In fact, HTTP 1.1 and a
variety of other specifications allow that relationship to be part of a
conversation, should a developer step up to the plate.  

The object element is at least a first step toward enabling that
conversation.  XInclude's "we'll cast whatever you send us" seems to
ignore it completely.  Caveat emptor or somesuch.
-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org

Received on Monday, 30 December 2002 21:53:05 UTC