W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2004

Re: ACTION: elaborate on 4.4

From: Kendall Clark <kendall@monkeyfist.com>
Date: Tue, 8 Jun 2004 17:06:20 -0400
To: public-rdf-dawg@w3.org
Message-ID: <20040608210620.GC15635@monkeyfist.com>

On Mon, Jun 07, 2004 at 01:17:39PM -0400, Kendall Clark wrote:

> Open design issues (many of which I expect can be analogized to
> content negotiation in HTTP) include:
>    
>    - how to request one's preferred exchange serialization; 
>    - whether it's a request or a negotiation;
>    - whether to identify exchange serializations by Internet Media Type, by
>      URI, or by canonical short name;

Just to be clear, the IMT option won't really work here. IMT aren't
generally fine-grained enough to distinguish different XML
vocabularies (which sucks, really). I think, then, short-name or URI
are the real options.

I'd be happy to design for 4.4 v. simply[1]:

    Put a bit in our doc about (1) HTTP content-negotiation and (2)
    come up with a set of (or a way to generate a set of) canonical
    names for various serialization formats.

I believe we'd need to do (2) because, IIRC, the con-neg spec talks
about IMTs. I just *assume* people are going to use con-neg if we give
them an HTTP binding for our protocol and don't say anything about all
of this. Except that then they'll have an interop nightmare because we
won't have done (2).

Best,
Kendall

[1] What I'd really like to see, vis-a-vis design, is an RDF
vocabulary to make assertions about the properties of DAWG origin
servers. The HTTP spec even gives us a very elegant (IMO) discovery
mechanism using OPTIONS and (slightly extending) OPTIONS *. Such a
vocabulary could assert which serialization types, identified by URI,
the server is prepared to offer, as well as other gooey bits of
metadata-y goodness.
Received on Tuesday, 8 June 2004 17:11:09 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:19 GMT