Re: Comments on element traversl specification (multiple responses)

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. 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.
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.

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)
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).

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.

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.

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.

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.

Ray Whitmer

Received on Monday, 28 May 2007 17:21:13 UTC