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

RE: Generic processing of Fragment IDs in RFC 3023bis

From: Grosso, Paul <pgrosso@ptc.com>
Date: Fri, 2 Jul 2010 11:40:08 -0400
Message-ID: <9B2DE9094C827E44988F5ADAA6A2C5DA484678@HQ-MAIL9.ptcnet.ptc.com>
To: <www-tag@w3.org>, "John Cowan" <cowan@ccil.org>
Cc: <public-xml-core-wg@w3.org>
[Forwarding to the list for John Cowan who is receiving email,
but not able to send at this time.  pbg]

The topic of fragment IDs for "+xml" media types was discussed in the
XML Core WG this week, and I'm posting this message as a result.  I
don't speak for the WG, however.

I believe that the ability to do generic processing on the majority of
"application/*+xml" media types is a very important one that should be
available by default rather than having to be enabled on a
case-by-case basis.  IMO, generic processing should permitted unless
either the media-type registration, or the general documentation of
the underlying format, specify otherwise.  That is, if the
documentation is silent, the meaning of a fragment ID is an XPointer,
as for the "application/xml" media type.  This avoids any need to
painfully go through and update all the existing registrations to
mention "application/xml" specifically where there is no sensible
alternative interpretation of fragment IDs.

This rule will mean that every fragment-id has a single universal
meaning.  Some processors will not understand particular media types
and so will misinterpret fragment IDs, but this is inevitable -- there
is no such thing as perfection in exception processing, as there are
almost always more exceptions than the current version of your
software knows about.  (Most people don't know quite all the irregular
nouns and verbs of English, and occasionally say things like "oxes"
instead of "oxen" or "smited" instead of "smote", causing those who
know better to wince.  So it goes.)  The failure to understand the
fragment ID in such a case is like the failure of a minimal XML parser
to understand certain entity references because it is not validating
and hasn't read the DTD.  It's a fail, but not an epic one.

I am in favor of a warning about the potential dangers of generic
fragment ID processing, but not a warning against doing it at all,
much less a prohibition.

Lastly, there is no particular reason why generic processing should be
limited to "application/*+xml".  A format like "image/foobar+xml"
might also be registered and should have all the benefits of generic
processing.  This point is independent of fragment IDs, but I mention
it here because I've just thought of it.

John Cowan

-- 
GMail doesn't have rotating .sigs, but you can see mine at
http://www.ccil.org/~cowan/signatures
Received on Friday, 2 July 2010 15:41:51 UTC

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