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
>
