Hi Ethan.
On 05/20/09 14:57, Ethan Quach wrote:
>
>
> Ethan Quach wrote:
>>
>>
>> Evan Layton wrote:
>>> I think that providing the information that there was a mis-match
>>> falls under the XML parsing work. It needs to find the mis-match
>>> collect the relevant information about that mis-match and report
>>> that back to the caller.
>>
>> This tells me the parser is responsible for semantically validating
>> the meanings of the
>> values in the manifest. I am highly against this. IMO, parsers
>> syntactically validate,
>> not semantically.
It depends on how you view the whole structure. I have viewed semantic
validation input files (defval manifest, etc) as part of the client's
deliverables, since it is directly tied to how the client works. (Note
that I didn't say the validator itself is part of the client's
deliverables.)
For the purposes of design, I can see how this inter-relatedness of
these files can muddy the boundaries though...
>
> Wait, I'm assuming that what you're talking about here is the
> validation of the
> repository specification in the manifest; if that's not what you're
> talking about, then
> nevermind my whole response...
Why should one field (repo spec) be thought of as different than other
fields, w.r.t. module (parser vs its client) boundaries? All fields
either validate or they don't.
For that matter, why should syntactic validation be treated differently
than semantic validation?
Thanks,
Jack
>
>
> -ethan
>
>>
>>> Once that's done then yes it would be up to the AI client to deal
>>> with perhaps logging the error or additional information but that
>>> information should come from the parser.
>>
>> So why shouldn't the parser layer just pass the value itself back to
>> the AI client (or
>> whatever is doing the semantic validation), and this error
>> information flows from that
>> point on.
>>
>>
>> -ethan
