Hi, Ray-
I think you have attributed to malice what can more accurately be
attributed to ignorance. I apologize if I unintentionally gave you the
impression that I was dismissing your use case, when what I was trying
to do was give you an opportunity to suggest a new API that addresses
it, since it is (as you agree) out of scope for ElementTraversal. Maybe
I simply didn't correctly understand what you're trying to accomplish,
since (as I admitted), I've never encountered your use case.
By the same token, I'd ask you to adopt a less accusatory tone, and to
assume all parties are acting in good faith. You catch more flies with
honey than with vinegar.
Replies inline...
Ray David Whitmer wrote:
Doug Schepers wrote:
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?
You have significantly mis-characterized the use case. So let me make my
own characterization of the API model, which obviously are free to
disagree with:
The API approaches the problem of element processing in an attitude that
doesn't care if there happens to be text chunks floating around in your
element content.
Correct.
I find this slip-shod, and part of a wider set of
attitudes responsible for the state of markup content on the internet
not being interoperable or accomplishing what the authors set out to do.
I honestly fail to see how.
But enough people program that way that you will probably find a willing
audience who says, yes, that is exactly what I want, because content is
slip-shod on the internet due to browsers that allow you to get away
with anything and interpret it one way or the other.
Browsers do tend to be forgiving, but again, I'm not sure how an API
that skips over non-element nodes would contribute to this.
There were exactly two cases I mentioned:
1. processing element content (with error reporting when it turns out to
not be mixed content, which should never be out of scope, unless content
is prevalidated)
It's become clear to me that I may not understand what you mean by this,
and why you feel it is of such importance. I gave you an example to try
to illustrate my point; did that not represent what you're addressing?
If not, I'd appreciate a concrete example.
If I have misunderstood you (as it seems I may), perhaps there is a
place for it in this spec (though I admit I am skeptical). Either way,
it will be good to get on the same page.
2. processing mixed content with an extra optional argument (which I
admitted might be out of scope, and I was and am happy to stop discussing).
I do believe this to be out of scope.
My first and most important use case is simple element traversal, of the
most-common sort, and your attempts to characterize it otherwise is not
justifiable. What the API describes allows accidental traversal of mixed
content when you intended to process element content, which is seldom,
in my experience, what anyone actually wants because non-whitespace
content is always relevant, even if you thought you were processing
element content -- enough that I would recommend that no one attempting
traversal of element content use the API.
Again, I think an example would clear this up for me.
Yes, I can perform element processing today by making my own utility
functions. It is not because I am solving different problems, I believe,
but because I insist on tighter processing and not silently ignoring
chunks of text that happen to be floating around in the content I am
processing.
...while this API is designed to do exactly that: ignore any content
that is not an element. If I didn't make that clear in the spec, can
you point to what gives any other impression?
When I mentor people on processing XML content using APIs, I will
continue to characterize an API such as yours as slipshod because it
ignores significant chunks of stuff that should seldom be ignored
floating around in the input stream, but whatever you like, you will
ultimately get. A responsible specification of an API of this sort would
at least warn people of this problem.
Why do you think it shouldn't be ignored? You've said that a few times
now, but you haven't offered a concrete example of something that is
relevant to iterating through element nodes. As was mentioned before,
even though this API only allows you to step between various element
nodes, it can be used in combination with other APIs to handle mixed
content if desired.
Feel free to ignore this response, but I will continue to respond to
mischaracterizations. You might also point to the feature of my writings
that ever mentioned anything about "cleanup" of mixed content, as you
suggest.
Your use of the word "processing" also gave me the impression that what
you were looking for was something more than simple navigation, which is
the essential purpose of this spec.
I extrapolated from your statements that you might "detect the
(erroneous) presence of non-element content", and was suggesting that an
API that meets your needs may include some method of cleaning up
"erroneous" content. I didn't imply that you stated that... I was
taking it a step further in trying to fully scope out what the utility
of such an API might do.
Let me explain briefly some of the desire considerations that went into
this spec:
* it must provide the (script) author with a manner of navigation that
is consistent across browsers (where there is sometimes inconsistency in
reporting the number and type of child nodes);
* it must be easy to implement, so that there is a greater chance of
browsers including it, so that in turn authors can depend on its
presence (which has not been the case with DOM Level 2 Range & Traversal);
* it must provide a small memory footprint.
My concern is that making the changes you suggest would undermine the
first 2 of these goals (and possibly the 3rd).
Regards-
-Doug
