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
