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