W3C home > Mailing lists > Public > www-tag@w3.org > January 2002

Re: Media types

From: Gavin Thomas Nicol <gtn@rbii.com>
Date: Wed, 16 Jan 2002 21:26:22 -0500
To: Paul Prescod <paul@prescod.net>, www-tag@w3.org
Message-Id: <E16R2fH-0007Yr-00@server2000.ebizhostingsolutions.com>
On Tuesday 15 January 2002 06:00 pm, Paul Prescod wrote:
> We're talking on two different levels. One is the level of platonic
> ideals. What specifications does this pile of bits conform to and
> what was the author's intent. A second is making stuff work with
> software. If we don't know what the right thing is then we can't
> figure out how to make software do it.

I agree that we need to know the ideal. My feeling is that there are 
two modes of operation: 
 
  1) The information producer sends something out they 
       want interpreted in specific ways.

  2) The information consumer wishes to interpret the data as they
      chose.

Thinking about the mixed XSL/HTML case, the producer might want it 
interpreted as XSL, and only as XSL, whereas the consumer might choose 
to see either XSL or HTML, or plain 'ol XML. In other words the 
producer "asserts" a type, and the consumer "projects" or "infers" a 
type on the data.

> The receiver chooses the processor. Server-declared type is an input
> into the decision making process.

Right. If the information is present, the consumer can use it.

> > ... In HTTP (and in MIME in general), the MIME type
> > is used to determine the *processing* (typically a
> > viewing/playback processor, but not necessarily)... so this is one
> > means toward that end.
>
> And another would be....what?

Extended TR9401 catalogs/catalog-based MIME packaging, an XML 
processing specification, a SOAP message....

> The receiver knows what it is trying to do: view, edit, index, etc.
> The receiver knows the set of software components available to it.
> The sender knows more about the actual data than the receiver does.
> So it should supply metadata that will help the receiver to make its
> decision.

Agreed. I'm more or less saying that the current type assertion are 
too weak, and that the connection between type and associated 
processing is also weak... after all, you can render an XML document 
any number of ways. We need to strengthen these bits in the 
architecture. My gut tells me that MIME ain't going to cut it (though 
it might be one part of it).

> The server-declared type is one important piece of metadata that the
> client can use to determine what component it should use. It is
> probably not the only thing it uses but it is an important part of
> the decision making process. So it is not irrelevant by any stretch.

It's irrelevant in the sense that the client is not *bound* by it. 

Obviously, the consumer is not under the producer's control. In the 
web, as it stands, the produced data is also largely out of the 
producer's control. I think we need a better means for the producer to 
specify allowed consumption behaviours, and a means to constrain the 
processing to only those behaviours. 

I guess if you twist your head a little sideways and squint, I'm 
proposing that we need something roughly akin to capabilities... where 
the capability is to a processing specification (closure in the 
abstract). There are obviously all kinds of DRM issues etc in this.
Received on Wednesday, 16 January 2002 21:53:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:04 GMT