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

Re: Generic processing of Fragment IDs in RFC 3023bis

From: Jonathan Rees <jar@creativecommons.org>
Date: Tue, 29 Jun 2010 09:56:13 -0400
Message-ID: <AANLkTimp8y72eytkZ414cW5ziaqPAQsfLP9DEmci_9hC@mail.gmail.com>
To: "MURATA Makoto (FAMILY Given)" <eb2m-mrt@asahi-net.or.jp>
Cc: Noah Mendelsohn <nrm@arcanedomain.com>, Chris Lilley <chris@w3.org>, "www-tag@w3.org" <www-tag@w3.org>
On Tue, Jun 29, 2010 at 4:28 AM, MURATA Makoto (FAMILY Given)
<eb2m-mrt@asahi-net.or.jp> wrote:
> Noah,
>
> Thank you for your mail and providing information about
> application/rdf+xml.  I  wonder if the TAG has also considered
> about the possibility of explicitly mentioning application/rdf+xml as an
> exception of generic handling of fragment identifiers and providing
> an exhaustive list of such exceptional media types in RFC3023bis.

Interesting you should ask. We did consider four options and this was
one of them. I think Larry on a recent telcon gave the best rationale
for preferring the solution we did over this one, which is that (a)
there is an unknown number of other +xml registrations that also
conflict with this kind of generic processing, and tracking down,
analyzing, and mitigating each one would be hard, and (b) there is
little assurance that future +xml registrations won't do the same
thing as rdf+xml and others, and specify fragid semantics that
conflict with generic processing.

If I remember correctly, the other options that we considered besides
these two were: serve RDF using application/rdf instead of
application/rdf+xml; and don't worry about the problem since it is so
unlikely to matter in practice.

Best
Jonathan

> Cheers,
> MURATA Makoto
>
Received on Tuesday, 29 June 2010 13:56:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:06 UTC