Re: Comments on element traversl specification (multiple responses)

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