Jack, As we discussed on the phone. I agree this is the correct approach.
Joe Jack Schwartz wrote: > Hi everyone. > > Last night I realized that I have to do checks for both values and > ranges in the code. Here's why . > > Ranges are "implemented" in the schema as a <list> with a pair of values. > > The way the schema processes lists is to create a single string with > all list items. So whether a (single) value or a (multi-value) range > (in the form of a list) is passed, both show up to the code as a > single string. The code needs to split the string and count the > individual pieces to know how many pieces have been passed. This > counting is how I "validate" that ranges have 2 items and values have 1. > > The schema still keeps the pattern checking for ranges (option 4 > below) for the reasons I mentioned yesterday. We don't want to > introduce (string/string) pairs for a range since the issue of faulty > validation occurring with > <range> > <choice> > <list> > <string> > <string> > </list> > <list> > <something more restricted than a string> > <string> > </list> > </choice> > > still needs to be accounted for. If, for example, a range of IP > addresses were validated by the string/string list above, other stuff > which needs to be validated by the second <list> entry will fall back > to being validated as (string/string) by the first <list> entry when > it should fail validation. > > I will be posting a webrev later today of my changes. > > Thanks, > Jack > > > On 04/01/09 16:27, Jack Schwartz wrote: >> Hi everyone. >> >> I am working on bug: >> 4325 Better syntactic treatment of IP and MAC address AI criteria* >> >> *new synopsis. Was "Implement data types for A/I criteria on server >> side" >> >> I had an issue with how to define changes in the criteria schema, to >> handle checking of singles and pairs of IP address and MAC >> addresses. The patterns enforcing IP addr and MAC addr formats >> themselves are OK, but how they interact with other choices for the >> same entries present either syntactic (validation) problems or >> inconsistency/usability/potential-user-confusion problems. >> >> The heart of the syntactic issue is that when the schema presents a >> choice of a string or a restricted pattern (e.g. ddd.ddd.ddd.ddd of >> an IP addr), an invalid char in an IP addr will fallback to >> inappropriately validate as a string. I can work around this, but >> this presents the confusion problem. >> >> Here are the options I came up with, and their problems, and what I >> think is the best solution: >> >> 1) I discovered the problem when I had to envelope a single IP addr >> inside >> <range> </range> >> when there was only a single value, and not a pair of values (to >> represent min and max of a range). This works, but the schema also >> has <value> </value>, and the single value listed as a range is a >> "value" not a "range". >> >> 2) Have types for MAC and IPaddr, in addition to '"value" and "range" >> for single values. This gets back to the problem of offering a >> choice of a string and a more restricted pattern. >> >> 3) Treat MAC and IPaddresses as strings in the schema, and check for >> proper punctuation (colons, dots) in the code. Ranges present a >> problem though, since there will be (string, string) pairs, which >> will negate current checking of (long/string, string/long) pairs >> which already exist and are checked correctly. >> >> 4) Check format of pairs of IP addresses or pairs of MAC addresses in >> the schema; and pass single IP or MAC addresses as strings through >> the schema and check them in the code. This prevents having >> (string/string) pairs (which present the problem with (3)). >> Currently there is a string type for single <value>s, so there is no >> conflict there. Pairs of addresses making a <range> are OK too, >> since there currently is no (string, string) range pair to negate >> it's checking. Singles and pairs are treated clearly and >> consistently in the schema. And while MAC and IP singles and pairs >> are treated differently in the code, I can document the code as why >> I'm doing this. >> >> (4) is the best solution I can come up with. If anyone has other >> ideas, please shoot them over to me ASAP (before tomorrow lunch), as >> I have to get this bug done in the next few days. >> >> Thanks, >> Jack >> > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
