- From: Jonathan Rees <jar@creativecommons.org>
- Date: Fri, 14 Jan 2011 08:53:03 -0500
- To: www-tag@w3.org
I'm not very fluent in the XML stack, so please correct me if I'm wrong... but... Suppose I retrieve, using a URI U, a 'representation' R1 with media type application/xml. Its xml:id attributes define some set of fragids, and any fragids not defined by xml:id (or equivalent according to DTD or schema??) are defined to be in error. (This is what's getting us in trouble with RDFa.) Call this set of fragids F1. If the base URI is U, then we have URIs U#id for all id in F1 valid, and U#id for id not in F1 erroneous. Now suppose that a style sheet transforms the 'representation' into a new XML document R2. That XML document will similarly define a set of valid fragids F2. Again, if the base URI is U, then U#id is valid for id in F2, and U#id is erroneous for id not in F2. Nothing says that F1 and F2 have to be the same set, and even for ids that are in both sets they could easily be defined by R1 and R2 to "identify" different elements. If I'm right - and tell me if I'm not - this adds to our growing list of apparent fragid inconsistency threats: 1. different interpretations in different representations (conneg, session, user-agent, caching, etc.) 2. different interpretations from different specs applied to a single representation (e.g. xml vs. +xml, or *ml vs. RDFa) 3. different interpretations at different pipeline stages (style sheets, GRDDL) I wouldn't be surprised if there were more. Two questions - first, does this make sense? And second, the TAG had some communication with the HTTP WG around #1, which unfortunately I can't find right now, either in www-tag email or in the HTTPbis draft. I would appreciate a reference to this, if someone has it handy. The remarkable thing to me is that such a mess at the level of the specs does not seem to lead (yet) to any particular problem in practice. That is pretty interesting. Jonathan (re ACTION-509)
Received on Friday, 14 January 2011 13:53:31 UTC