On 12/04/13 23:17, Eric Blake wrote:
On 04/12/2013 08:38 AM, Laine Stump wrote:
On 04/12/2013 05:21 AM, Osier Yang wrote:
---
Your conversion is fine, but this does highlight that the code here
interprets *everything* except "off" as "on" (including "OFF", "no",
"Off", "0").
There are actually many similar instances in the parser code. Should we
continue to be so silently strict? Or complain any time the string isn't
*exactly* "on" or "off"? Or make it extremely tolerant about what is
entered (0, off, Off, no, false all mean the same thing)?
It also begs the question - is our .rng schema capable of parsing the
same set of options as our C code accepts, and flagging the typos?
As far as I saw from the parsing code, the answer is "no", applies for
most of the parser.
Is it worth making a helper function that takes a const char * and
returns true/false according to whatever rules we decide, then use that
everywhere there is an on/off (or yes/no) attribute?
Yes, I think having a common parse helper function, as well as using a
common <define> throughout the RNG schema that accepts the same things
as the C code, would go a long way to making this friendlier to users.
Agreed, this can reduce much redundant code.
I also think that adding a way to canonicalize an XML snippet, including
the option to reject it if it fails the RNG schema, would be a helpful
addition to the API (we've mentioned the idea in the past, but it has
not been implemented yet).
It was on my plate, feel sorry for I didn't finish it, though once raised
up the proposal. Anyway, I was planning to pick it up again recently.
Except the API, validating the XML when define the objects is nice to
have too (though I'm a bit worried about the regressions, as the RNG
schema could also have bugs).
Osier
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list