Re: Comments on element traversl specification (multiple responses)

There were several responses to my comments. None solved any use case  
I raised or made a case for an API I could use instead of DOM for  
either simple element or mixed processing. Since the responses  
referred to each other and I did not receive them in my in box, I will  
attempt to make responses in a single response.

I realize that this is a proposal for an element processing model,  
which would be expected to map to requirements for processing element  
content, not mixed content. The suggestion of an added argument was  
only to solve infrequent mixed content processing. If I have to write  
my own procedures for that, it is expected. But the specification is  
still useless to me reliably processing element content because an  
essential part of that, in my experience, is verifying the assumption  
as I go that it is, indeed element content.

David writes:
"Why not just ignore it? It's very useful to be able to traverse the
element tree without taking text nodes into account at all. Just look
at CSS, it is purely concerned with element nodes (and  
pseudo-elements). We already have  
nextSibling/previousSibling/firstChild/lastChild/parentNode for the
case of being interested in other types of nodes."

Response:
If it is comments or white space, I agree. If not, then it was  
generally not placed there to be ignored. If we expected to receive  
element content and it turned out to be mixed content it is never in  
any application I have written satisfactory to ignore that the mixed  
content exists.

Jonas Writes:
"In any case, using element traversal you can decently easy check if
content is skipped so that you can indicate an error, simply check if
myElem.nextElementSibling != myElem.nextSibling"

Response:
Unfortunately, that does not solve any problem that I have raised,  
since a document can easily have intervening content, such as comments  
or white space, which may be commonly safely ignored in element  
content, so determining whether there is content skipped doesn't tell  
you anything useful about whether there is content that is not element  
content. Does this API apply only to environments where white space or  
comments in element content are 100% removed?

Cameron writes:
"  || myElement.nextSibling.isElementContentWhitespace
which is I think what Ray was after.  But I agree, having
ElementTraversal always ignore Text nodes will be more useful than
defining .{next,previous}ElementOrUsefulTextSibling methods."

Response:
This acknowledges that the prior comment missed the requirement, but  
also does not solve the problem. If, for example, the element is  
followed by white space and then a comment, etc.

Maciej writes:
"You don't want to append them as children, because that would remove
them from the original document; you could clone them instead, but
that is expensive performance-wise and does not preserve node
identity. At this point, we have a pretty narrow range of use cases
which would be better served with (in my opinion) normal DOM
traversal plus a way to detect whether a text node contains
significant content."

Response:
I said the content should be copied, not moved. I know the difference.  
As I stated at the start of this message, processing mixed content is  
admittedly a narrower case than processing element content, and many  
document types do not contain it.

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.

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.

Thanks for your responses,

Ray Whitmer

Received on Sunday, 27 May 2007 11:59:19 UTC