Hi Dave and Jack, >>>> >>> >>> I'd view it as an important requirement that we be able to perform >>> full semantic verification on the server. Why is this regarded as >>> optional? >> It's not that it's optional on the server, it's that the server >> cannot provide the full client context to do full validation. Of >> course we want to do as much validation as we can on both the server >> and the client. >> > > I would expect that a user could supply whatever context we desire to > use, either synthetically or via importation of some client context > that was generated from a real client. From the point of view of the > validator, the client is just a bunch of parameters, which can also be > supplied via other avenues. Requiring real, live clients in order to > validate thus seems unnecessary.
I don't think in all validation scenarios we require real, live clients. But, we have to know that some validation is not possible if we don't have the context for which we are doing the validation. The issue with some of the semantic validation, specific to the client, is that beyond simple 'syntax' checking or format checking of something like a target device specification, without a live client or a set of client data that provides this information, it is hard to validate the schema. So, are you proposing we provide for 'importing' the client data if the user so desires so we can do more contextual validation when setting up a service? I am not sure why we would want to do that actually. Seems to me a service is independent of the client. Clients discover services, and one service will be used to produce an installed system, but the manifests that are provided in that service may apply to many clients. Providing this contextual semantic validation as a user is setting up a service seems to break what our model is. As you note, we would have to have some data regarding the client to do this type of validation, which implies that the user setting up the service would have to know which clients the service applied to, if they wanted to make use of it. During specific client setup, that is installadm create-client, we could do this. sarah **** > >> In response to your reply to Clay: >> > Wouldn't it be desirable to be able to construct a virtual validation >> > "environment" on the server based on user input? Let them specify >> > the disk configuration, the memory, etc. and validate against it. >> Such >> > functionality would seem to be necessary in order to effectively test >> > this, wouldn't it? >> >> Please elaborate, because as I understand, I'm not sure this is >> feasible so I may just not get what you're saying. >> >> For example, as Clay said in his first response, in the case of a >> disk configuration, how would the user know that such a disk by that >> name really exists on the client? We can't assume the client is up >> and available, or even if it is up, that the disk would have that >> name in its currently-booted OS instance. > > See my note above about synthetic environments. If our only answer to > testing out sets of criteria is to "boot and hope", then I think we've > fallen far short of what's possible. > >>> >>>> Problem statement 1: AI's multiple parsers present unneeded >>>> complexity and unmaintainability. >>>> =========================================================== >>>> - Things to consider for a single parser: >>>> - functionality for data retrieval and search, schema compatibility, >>>> how supported / maintainable is the parser >>> ... >>>> The main argument for using lxml would be that it is supported from >>>> the >>>> outside. However, that ManifestServ is supported by us means we >>>> can more >>>> easily tweek it to add any needed functionality which remains. If >>>> lxml were >>>> used, we would have to fix our code which interfaced with it if it >>>> changed, but >>>> we would have to do the same for ManifestServ if libxml2 changed. >>>> >>> >>> It wasn't entirely clear from the discussion in the notes that we've >>> actually identified requirements that lxml doesn't meet. Do we have >>> that? >> lxml meets most of the requirements we would need, but it would >> require some work writing new wrapper code to use it, and >> ManifestServ has this already done. For example, lxml does have >> something we can use for semantic validation but would require event >> handlers and other code to make it work. ManifestServ already >> presents a complete system for this using libxml2. lxml won't buy us >> anything more than what ManifestServ already delivers, and will >> require an effort to make it useful which isn't required with >> ManifestServ. >> >> One shortcoming of lxml vs ManifestServ is that it doesn't have as >> good of a capability for narrowing of matches based on values of >> multiple child nodes. >> > > I don't have any particular bias one way or another, but there's > up-front vs. on-going effort involved in any choice made, and I'd > expect to see some evaluation of those trade-offs in the design proposal. > > Dave > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
