Re: Content negotiation issues (was XInclude)

>From: "Simon St.Laurent" <simonstl@simonstl.com>
>
>ralinon@hotmail.com (Jeremy Dunck) writes:
<snipped spec quote>
> >
> >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.

I read it as a way for the author to hint to the UA what content it might 
expect.  This is an optional preemptive filter before the HTTP request is 
ever made.  Content negotiation in the context of the HTTP request still 
happens as normal.  If someone used type="foo/bar", and the UA didn't fetch 
the resource because of "foo/bar" is an unsupported content type, it's the 
author's fault, even if the real resource might have returned "text/css".

I think it's merely an optimization tool, and completely separate from 
content negotiation.

> >>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.

I don't read the specification that way.  I see that a normal (probably 
HTTP) request is made for the resource, and the protocol does whatever 
content negotiation it would normally do... separately from the UA's 
intended purpose for the representation.

Now, if you're saying that given XInclude's parse="xml", a smart XInclude 
processor might limit the ACCEPT to XML mime types, then I agree with you... 
and it might be good for the spec to make such a suggestion.


> ><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.
>

By this, you mean that UAs supporting a particular specification should 
limit (in the case of HTTP) ACCEPT headers to MIME types encompassed by the 
specification?  Or did I still misunderstand?

>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.

Again, see comment above regarding (my perception that) the independence of 
HTML's type attribute and the content negotiation supported by HTTP.

Thanks,
  Jeremy

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

Received on Tuesday, 31 December 2002 11:24:08 UTC