Hi William.
Thanks for your inputs.
On 05/21/09 06:47, William Schumann wrote:
> Jack,
>
> Jack Schwartz wrote:
>>
>> On 05/18/09 04:22, William Schumann wrote:
>> ...
>>> Sematic validation:
>>> This could be done in a separate library so that it can be used by
>>> AI both on the client and on the AI server. The semantics will be
>>> identical on both.
>> Please elaborate. What would go into this library?
> First, I would like to further classify validation.
> A) RelaxNG validation - very basic datatypes
> B) semantic validation - validity checking according to data types
> beyond RelaxNG
> C) application-specific validation - e.g., checking for
> mutually-exclusive elements and elements that are required in certain
> combinations by the application - in this instance, AI
> D) install-time validation - when Target Discovery information is
> available
Well, what I've been calling semantic validation is any validation
beyond the syntax checking of RelaxNG. This includes B, C and D.
Anyhow, continuing...
>
> Now, optimally, the server should have A, B, and C, where the client
> needs also D.
>
> RelaxNG has a very limited set of datatypes. URLs, for example, are
> not recognized. This is where the semantic validation would come in.
> Since there is no URL datatype, any elements that are URLs would have
> to be known by the semantic parser.
RelaxNG does patterns, but using a "semantic" parser as I've been
calling it seems easier to implement for checking and looks cleaner to me.
ManifestServ will be replaced by lxml. I'll interpret ManifestServ
below as whatever its replacement (wrapper code around lxml) will be.
>
> Possible approaches to handling semantic validation (B) and maybe
> application-specific validation (C):
> 1- extend RelaxNG schema by adding new datatypes such as URL, and make
> ManifestServ handle the new datatypes
These would be patterns.
> 2- have code that ManifestServ calls to do the extra validation based
> on user-specific elements. The IPS repository, for example, is an
> URL, and it is used in two different elements: the primary repository
> and the mirror. ai_repo_name and ai_mirror_name would be validated here
So we would be validating the IPS repo by validating the elements that
refer to it.
> 3- have a separate library that handles semantic (B) and
> application-specific (C) validation outside of ManifestServ
>
> I propose a separate library to handle semantic validation (B) that
> also has code for application-specific validation (C) (could also be 2
> separate libraries).
> installadm and auto-install consume this library (on server and client).
>
> The library is a layer between AI and ManifestServ. It uses
> ManifestServ to do basic RelaxNG parsing, performs semantic and
> application-specific validation, and services requests such as, return
> the element X, return list elements in X[], return all child elements
> of X, etc.
... or just fix the parser to return what you want. This can be written
into the new wrapper code around lxml.
>
> install-time validation (D) is performed by auto-install, only.
Yes.
Thanks,
Jack
>
> William
