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
