- From: Dan Brickley <danbri@danbri.org>
- Date: Thu, 24 Jun 2010 16:45:22 +0200
- To: Norman Walsh <ndw@nwalsh.com>
- Cc: www-tag@w3.org
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