- From: Jan Algermissen <algermissen1971@mac.com>
- Date: Mon, 05 Apr 2010 21:27:35 +0200
- To: Erik Hetzner <erik.hetzner@ucop.edu>
- Cc: www-tag@w3.org
On Apr 5, 2010, at 8:09 PM, Erik Hetzner wrote: > At Mon, 05 Apr 2010 01:27:36 +0200, > Jan Algermissen wrote: >> I usually address the subclassing issue (which is primarily an issue >> of expressing a client side capability of expectation, IMHO) with >> a profile parameter on the media type(s) in the Accept header: >> >> Accept: application/rdf+xml;profile=http://xmlns.com/foaf/0.1/ >> >> The server can respond with just Content-Type: application/rdf+xml or, >> if desired, with a 406 Not Acceptable if the profile 'request' cannot >> be satisfied. > > I want this solution to work, but I have some concerns. > > Is there a profile parameter defined for the application/rdf+xml media > type? (I don’t believe there is.) It is defined for HTML and, IIRC, XML, too. It would be straight-forward to define it to apply to any media type, IMHO. However, it is just something I have used somewhere. It does not mean it is a good or the best solution. What I think matters most is to document the client's expectation somehow. The rest will be figured out at runtime anyhow. Jan > Or is profile considered an HTTP > accept-param? If the latter, shouldn’t it follow a q param? Futher, if > it is an accept-param, am I right in thinking that the Content-Type > response will not return the profile value? > > best, > Erik Hetzner > ;; Erik Hetzner, California Digital Library > ;; gnupg key id: 1024D/01DB07E3 ----------------------------------- Jan Algermissen, Consultant NORD Software Consulting Mail: algermissen@acm.org Blog: http://www.nordsc.com/blog/ Work: http://www.nordsc.com/ -----------------------------------
Received on Monday, 5 April 2010 19:28:29 UTC