W3C home > Mailing lists > Public > www-tag@w3.org > June 2010

Generic processing of Fragment IDs in RFC 3023bis

From: Noah Mendelsohn <nrm@arcanedomain.com>
Date: Tue, 22 Jun 2010 21:21:22 -0400
Message-ID: <4C216192.5030508@arcanedomain.com>
To: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>, Chris Lilley <chris@w3.org>
CC: "www-tag@w3.org" <www-tag@w3.org>
This is a comment on RFC 3023 bis [1].

At its recent face-to-face meeting in London, the TAG discussed in some
detail the provisions in RFC 3023bis for generic processing of
fragment identifiers when Web "representations" have content types of
the form:  application/xxxx+xml.  Specifically, the current draft of
3023bis allows processors to interpret such fragment identifiers as if
the Content-type had been application/xml [2].

We agree that such generic processing is desirable in principle, but
unfortunately, media type application/rdf+xml is widely deployed, and
its specification mandates different treatment of fragment identifiers.
In the likely case where URIs for resources with application/rdf+xml
representations follow that specification, generic processing will lead
to incorrect results.  There may be other deployed media types for which
similar problems arise.

With some reluctance, the TAG therefore suggests that fragment 
identifier interpretation be removed from the generic processing list in 
section Y.Y [2], and that related descriptive text be updated 
appropriately.  In fact, it may be useful to provide some warning of the 
risks of generic processing of fragment identifiers.

In case it's of interest, the TAG did discuss some other possible
resolutions to this problem, including a suggestion that RDF/XML be
changed to a media type of application/rdf.  On balance, we feel that
the approach suggested here is likely to be the best way forward.

Thank you very much.

Noah Mendelsohn
for the W3C Technical Architecture Group

Received on Wednesday, 23 June 2010 01:21:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:34 UTC