On Tuesday, November 12, 2002, at 10:52 PM, Peter Donald wrote:
I am also working on factoring it out which includes supporting just rawkinda confused me here.. one aspect of the validation is auto-discovery of the schema files via some predefined rules? would this be a startup process, scan all classloaders for schemas and build a static catalog or build it on demand as a schema is needed?
descriptors with dtds/schemas discovered using a semi generic search process
(basically search specified classloader for files that act as a quasi-catalog
and use that to bootstrap the validation process).
Anyways I want to make it able to support all sorts of configration/xmlso this aspect is a DTD locator? loader/policy/info XML documents will have DTD reference in them and we'll just have to serve it up, similar to how phoenix works with the blockinfo files?
scenarios. In particular the DTDs in loader/policy/info projects need to be
found by this mechanism and used during validation process.
Anyways I will hold off doing any work on it until you tell me you are done ;)ok :) might be a week or so.. some of this will stuff to do while waiting in airports..
BTW I was also thinking of moving it into a new project (validator) because itthere will still need to be a link between the two.. or perhaps validation can be integrated into configuration building from XML in certain cases. (ie most things other than phoenix config.xml files that can't easily conform to a single schema).
would no longer be tied to configuration anymore.
but validation can be broken out into a new project with the configuration integration in a separate package. so i see the following pieces:
1) schema discovery
2) entity resolver using #1
3) validation API (maybe standardize JARV, or very light wrappers, since it already does just that. perhaps we could do away with specifying the schema-type and autodetect based on namespaces?)
4) component configuration validation.
3 and 4 are mostly done.. 1 and 2 need further analysis...
-pete
--
peter royal -> [EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
