Re: Comments on element traversl specification (multiple responses)

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

Received on Monday, 28 May 2007 19:17:54 UTC