Re: Generic processing of Fragment IDs in RFC 3023bis

Dan Brickley <danbri@danbri.org> 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. http://www.ietf.org/rfc/rfc3870.txt 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,
                                          norm

[1] http://lists.w3.org/Archives/Public/public-xml-core-wg/2010Jun/0018.html

-- 
Norman Walsh <ndw@nwalsh.com> | Debugging is 99% complete most of the
http://nwalsh.com/            | time--Fred Brooks, jr.