Re: Generic processing of Fragment IDs in RFC 3023bis

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.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | As the old hermit of Prague, that never
http://nwalsh.com/            | saw pen and ink, very wittily said to
                              | the niece of King Gorboduc, 'That that
                              | is, is'.-- Shakespeare