avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <donaldp@apache.org> (by way of Peter Donald <dona...@apache.org>)
Subject [Vote] Semi-structured and Validation
Date Sat, 24 Feb 2001 05:55:06 GMT
Hi,

I guess we are at an impass regarding config et al thread so perhaps it
would be best to just put it up to vote. There are three aspects to this
decision.

1. Should Configuration allowed to be semi-structured?
2. When should validation occur?
3. Should validation be context sensitive?

Semi-structured Configuration
-----------------------------

I say this is a very desirable attribute. The reason is that it integrates
well with existing practices and it allows avalon integration into a larger
body of work. For a public example of how this would be useful you can have
a look at the Ant2.0 proposal Myrmidon that uses the Avalon api.

Many existing products also use semi structured configurations which could
be a bad practice (thought I don't think so) but as such if we want to ease
development under Avalon apis then it would be desirable to allow this.

Fedes concern is that allowing semi-structured Configuration inside Blocks
is bad practice because it leads to difficulty in parsing and validating
config data by external service. This is largely true.

2. When should validation occur?
--------------------------------

In most cases I think it is agreed the answer is "as early as possible".
How should we react to config violations? I think that should be up to a
particular policy. Some people wand to fail fast and hard while others will
just remove elmenets and warn user etc.

The problem occurs when we have hierarchies of components defined in one
config file. At each container-child level it is largely impossible to
determine how to validate if the child configuration is pluggable.
Suggested solutions so far

a. place a xsd:schema="foo.xsd" (or whatever) in config file
b. not validate child components
c. not allow child components in container config
d. allow container to validate child components

I am -1 on (a) because it mixes concerns. (b) is default if no other action
is taken. I am +1 on either of (c) or (d) however both require significant
extra work.

3. Should validation be context sensitive?
------------------------------------------

The more I think about this the more I begin thinking no. Context
sensitivity while nice is too much work in the general case.

So we have two things to decide. How we handle Configuration validation in
general and how we handle it specifically in the phoenix kernel. Perhaps to
serve all parties we could to do the following.

* Allow only one validator for each top-level block and either implement 2b
or 2c
* Allow semi structured data. (for non-phoenix users of avalonapi).
* disallow context sensitive (ie external) validation

Naturally I am +1 on all the above ;)


Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*



------------------------------------------------------------
To subscribe:    java-apache-framework-on@list.working-dogs.com
To unsubscribe:  java-apache-framework-off@list.working-dogs.com
Problems?:       jon@working-dogs.com



Mime
View raw message