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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201408041457.s74EvXKg019899>