Re: HTML variants and content negotiation

On Tue, 16 Jan 1996, Leslie Daigle wrote:
> [Some time ago, Brian Behlendorf wrote:]
> 
> > II.  Introduce conditional constructs to HTML.  Basically create a new 
> > content-type, text/cond-html, say, and have it use either marked sections 
> > or PI's to implement a IF(feature|NOT feature), THEN (block) ELSE 
> > (block).  The "feature" would again be a registered keyword, which 
> > browsers would be responsible for setting appropriately.  Browsers which 
> > supported cond-html would indicate so in their accept headers of course, 
> > so there's still a big role for content negotiation.
> 
> Although this sounds like a smaller-granularity situation than MIME
> typically handles, would not the multipart/mixed and multipart/alternative 
> facilities of MIME be a useful way of handling this?  
> 
> Obvious advantages include the degree of standardization MIME has
> already gone through, and the fact that HTML is already using MIME
> constructs like Content-Type.

This led to an interesting hour or so of web spelunkering on my part, so 
I thank you for the suggestion.  

Multipart/mixed would seem to be inadequate - it describes a collection of
related objects but doesn't seem to describe how to relate them, or more
importantly, what the conditionals would be.  Or am I missing something? 
Next - anyone have a more current specification for multipart/alternative? 
The search I performed only came up with RFC1766, which claims
multipart/alternative is defined in RFC1541, but 1541 is actually the
definition of Dynamic Host Configuration Protocol - oops. 

Multipart/alternative would seem to be workable, IF the granularity of the
conditions at the level of Content-type was acceptible.  Given that web
browser builders don't declare their unique tag sets as separate types
anyways in Accept: headers, I think we'd run into the same situation.  That's
my third suggestion - quit evolving HTML and make everything EMBED'D, or as
much as possible at least.  If the MIME gods were to allow another value for
the "Differences" field, like Content-Extensions, say, then the browser
author could define the feature sets they support (be that through Murray's
modular DTD model, or a simple IANA registry) and apply tests to it, but 
I'm not convinced that would be flexible enough for what many content 
providers want to do.  It looks like the condition test in M/A is a 
straight equivalence, when in fact I see content developers wanting logic 
like AND, OR, NOT, ELSE, and maybe even > and <.  As someone said, 
everything "cpp" provides, in fact some of us use that server-side 
already.  :)  Finally it would more or less require each subdocument to 
be complete, rather than a fragment, which could also make it clunky to 
use.  I certainly wouldn't discourage implementation experiments, however.

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  brian@hyperreal.com  http://www.[hyperreal,organic].com/

Received on Wednesday, 17 January 1996 08:04:53 UTC