Re: Generic processing of Fragment IDs in RFC 3023bis

On Thu, Jun 24, 2010 at 4:36 PM, Norman Walsh <ndw@nwalsh.com> wrote:
> Noah Mendelsohn <nrm@arcanedomain.com> writes:
>> 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.
>
> I object! I consider the formal specification of a generic fragment
> identifier syntax for XML one of the key benefits of RFC 3023.
>
> A lot of the work that I've done in recent years (xml:id, XLink,
> XProc, and on the XPath 2.0 and XQuery 1.0 Data Model) has been done
> on the good faith assumption that RFC 3023 would eventually emerge
> From "bis" and formally sanction the use of #id fragment identifiers
> for generic XML.
>
> I routinely use tools implemented on the same good faith assumption.
>
> To have that rug pulled out from under me at this late stage would be
> deeply painful.
>
>> 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.
>
> Well I think you're wrong. Just because RDF has an...interesting
> definition of fragment identifiers is no reason to punish the rest of
> the XML world.

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?

Dan

Received on Thursday, 24 June 2010 14:45:55 UTC