- From: Doug Schepers <doug.schepers@vectoreal.com>
- Date: Sun, 27 May 2007 14:28:54 -0400
- To: Ray Whitmer <ray@jhax.net>
- Cc: public-webapi@w3.org
Hi, Ray- Ray Whitmer wrote: > > Doug writes: > "It doesn't seem to me that what you are looking for is in scope for > ElementTraversal. The whole point of ElementTraversal is that it > ignores all non-element content. This is most useful for languages such > as SVG where most content is not "markup" per se (that is, where > elements are themselves the content, and are not primarily used to > encapsulated text content). Of course, there are uses in HTML as well, > where most elements are in fact marking up text content (for example, it > might be used to walk a collection of <li> elements, while ignoring any > whitespace or comments between them)." > > Response: > If SVG can always count on the content having been validated so that > there is never any significant mixed content floating around in what > should have been element content, I accept that it was not intended to > be useful enough for general processing of element content, and this is > just an SVG-centric spec I should not expect to find useful. Again, it's not SVG-centric; it will work in any language, including HTML. It happens to be most useful in a language where a large proportion of the content is elements (as one might expect in an element traversal specification). It does not rely on SVG having been validated. SVG's rendering model is such that any text (including comments) that is not contained in a text content element (such as 'text', 'tspan', 'textPath', etc.) is not rendered. For example, the following fragment causes no problems for SVG: <svg version='1.1' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink'> <ellipse cx='125' cy='25' rx='25' ry='12' fill='indigo'/> This is junk, so it shouldn't be rendered. <!-- this is a comment --> <text x='10' y='25' font-size='18' fill='crimson'>This is not junk, so it will be rendered.</text> </svg> In this case, ElementTraversal will only ever "see" the <ellipse> and <text> elements, ignoring the others. As you say, this to be the most common use case for traversing elements. You are correct that it is not meant to be used for "general processing" of mixed-content, but rather the optimized navigation of element content (thus "element traversal"). > But for my purposes, any API like this would at least have to be able to > raise an exception or otherwise easily detect the (erroneous) presence > of non-element content, or it is of no use to me, since I generally do > not rely on pre-validated XML and it is essential for the application to > reject things that are so obviously wrong with the content like having > chunks of text sitting where they should not be. > > So, I continue to rely on my own methods for easy element traversal. I'm sorry that the ElementTraversal Spec doesn't meet your needs. What you are describing seems to be a sort of mixed-content processing/clean-up functionality, not "element traversal". I have no idea how common this use-case is; I've never encountered it myself, but maybe it's really common in mash-ups? If it's common enough, and if the code to deal with it is difficult to write, hard to maintain, too slow, or is otherwise problematic, perhaps we should consider writing different specification to address that. Do you think that's the case, or are do your own utility functions do the job correctly? Regards- -Doug
Received on Sunday, 27 May 2007 18:30:12 UTC