Hi Joe.
Thanks for your feedback.
Thanks,
Jack
On 04/03/09 03:45, Joseph J. VLcek wrote:
> 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
>
