XML Output: libxo - provide single API to output TXT, XML, JSON and HTML

[Phil Shafer]

John-Mark Gurney writes:
>The just pushed the error handling further down stream...  I'd trust
>a parse error more than someone handling all the odd edge cases of
>missing tags, or even failure to parse the error tag...

Yes, I'd rather see output that is obviously broken and prevents a
parser (JSON or XML) from returning success than parsable output
with a message that we're depending on the client to parse and case
about.  From phk's example, how many will write:

    grep --xpath some/tag/i/care/about `du --xml`

and not even notice the error tag, which would require something like:

    grep --xpath 'some[not(//error)]/tag/i/care/about' `du --xml`

where the cost of "//error" (searching the entire output tree for
an error tag) might be huge.  And doing this in JSON would be worse,
since there's no XPath for JSON (yet).

>Either choice we make pushes the error handling down stream... One case,
>it's the parser, the other case it's the consumer of the parser, but in
>both cases the downstream HAS to properly handle the error however it
>is signaled...

Sure, but I'd rather trust the parser library to say "this is junk"
than do trust the client app to handle exception information in the
output data.

Thanks,
 Phil