FW: Generic processing of Fragment IDs in RFC 3023bis

-----Original Message-----
From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf
Of Noah Mendelsohn
Sent: Tuesday, 2010 June 22 21:21
To: MURATA Makoto; Chris Lilley
Cc: www-tag@w3.org
Subject: Generic processing of Fragment IDs in RFC 3023bis

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

[1] 
http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.ht
ml
[2] 
http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.ht
ml#naming

Received on Wednesday, 23 June 2010 01:43:31 UTC