Re: Generic processing of Fragment IDs in RFC 3023bis

Dan Brickley <> writes:
> If RDF is the "odd one out" then it does seem ... unfortunate. The
> application/rdf+xml type has a good amount of deployment though, and
> it seems unfair to change the rules for those publishers by altering
> the meaning of their existing markup, links and data. Would a
> compromise design be to include a special case exception for
> application/rdf+xml in the generic processing rules? Hardly elegant,
> I'll grant you, but perhaps a reasonable compromise?

As I said when this thread popped up on the XML Core list[1]:

  I'm perfectly content with a world where

  1. defines the fragment identifier
     scheme for application/rdf+xml representations.

  2. RFC 3023 defines the fragment identifier scheme for
     application/*+xml representations.

  If I see an application/rdf+xml representation and I know about 1, I
  use it. Otherwise I use 2 and maybe I don't find the fragment or I
  find the wrong fragment and I move on with my life.

                                        Be seeing you,


Norman Walsh <> | Debugging is 99% complete most of the            | time--Fred Brooks, jr.

Received on Thursday, 24 June 2010 14:59:33 UTC