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