Date: Mon, 4 Aug 2014 10:57:33 -0400 From: Phil Shafer <phil@juniper.net> To: John-Mark Gurney <jmg@funkthat.com> Cc: arch@freebsd.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, "Simon J. Gerraty" <sjg@juniper.net>, Marcel Moolenaar <marcel@freebsd.org>, Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML Message-ID: <201408041457.s74EvXKg019899@idle.juniper.net> In-Reply-To: <20140801175906.GA50495@funkthat.com>
index | next in thread | previous in thread | raw e-mail
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
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201408041457.s74EvXKg019899>