- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Wed, 9 Jan 2008 17:03:25 +0200
- To: daniel@veillard.com
- Cc: Maciej Stachowiak <mjs@apple.com>, Timur Mehrvarz <timur.mehrvarz@web.de>, public-xml-core-wg@w3.org, public-cdf@w3.org, Eric Seidel <eric@webkit.org>
On Jan 9, 2008, at 16:05, Daniel Veillard wrote: > On Wed, Jan 09, 2008 at 12:07:14PM +0200, Henri Sivonen wrote: >> On Jan 9, 2008, at 07:01, Daniel Veillard wrote: >>> Do SVG implementation actually parse/handle the DTD embedded in Web >>> documents ? >> >> They don't generally. > [...] >>> I doubt it, in that case you rely on hardcoded behaviour of the >>> engine, >> >> You don't need to rely on SVG engine-level hardcoding if you move the >> hardcoding layer (at least conceptually) to between the XML processor >> and the DOM builder. After all, that's were you'd put an xml:id >> Processor. > [...] >>> What you are suggesting may be better from a code behaviour >>> viewpoint *now* but from an user data point of view, >>> generic processing, long term management of those, it sounds safer >>> to use an ID handled at the XML level, >> >> xml:id isn't on the XML level. It is immediately on one level above >> the XML level. > > Hum, strange that's not the case in my implementation, xml:id > is handled as if an internal subset had defined it as being of type ID > in the XML document, it's XML level, really. The best proof is that > it uses an 'xml' hardcoded prefix, it's below namespaces in practice. Norman Walsh's implementation is a SAX filter outside the XML processor. (My IDness assignment implementation is a SAX filter as well.) The formulation of xml:id processing using the notion of an xml:id Processor as a "software module that works in conjunction with an XML processor" supports the view that xml:id doesn't redefine the XML layer but adds a processing layer on top of it. Even if this processing layer is above the namespace layer, the namespace spec makes the "xml" prefix mapping hard-wired, so to order of xml:id and namespace processing don't make a practical difference. >> I'm suggesting assigning IDness to id in no namespace > > You are suggesting only specific tools can process the data > customers will > put on the web ? I'm suggesting that any application that wants to perform ID-sensitive operations on XHTML, SVG or MathML (or in the future XBL2) documents retrieved from the Web without a bilateral agreement with the document author about xml:id use has to and will have to treat the id attribute in no namespace as an attribute that participates in those operations. > [...] >>> There is certainly Web engine which don't recognize xml:id now, but >>> if the web content is targetting reuse and long lifetime I would >>> avoid relying just on the SVG hardcoded behaviour. >> >> Considering long life time, browsers can never stop supporting the >> IDness of id in no namespace on XHTML, MathML and SVG elements. > > Must be a yes to the previous question ... Well it is also sometimes > useful to extract data with generic tools, to automate processing. Generic tools could add a processing layer for assigning IDness to id in no namespace. (Implementations that don't report duplicate IDs and/ or that don't support CML can probably even ignore the CML grandfathering issue.) > I guess it all comes back from the original XML example of including > data > in Web pages and still be able to extract them as non-rendered content > useful for a wide variety of applications, not necessarilly a > dedicated > fat engine with hardcoded knowledge of a set of vocabularies. If an implementation doesn't report duplicate IDs, it can probably get away with not knowing about particular vocabularies and unconditionally assigning IDness to id in no namespace. > If it's the 'xml:' prefix which really itches you, I somehow > understand your fear of namesapce, but really this is just syntactic > sugar in that case and that reaction should really not lead to a > specialization of tools to process the customer data, it's really > not worth it ! What itches me is introducing the 'xml:' prefix so late that it cannot be used exclusively due to backwards compatibility issues. When it cannot be used exclusively, it doesn't solve a problem but only makes it more complex. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Wednesday, 9 January 2008 15:03:47 UTC