avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [Vote] Namespace support for Configuration objects
Date Mon, 01 Oct 2001 14:28:32 GMT

> -----Original Message-----
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> Sent: den 1 oktober 2001 15:21
> To: Avalon Development
> Subject: Re: [Vote] Namespace support for Configuration objects
> I agree with you, W3C DOM APIs are painful to use. But don't you think
> that by adding namespace in Configuration, and then selection by
> namespace and then... , you will end up with a yet another java-friendly
> equivalent to DOM when there are already JDOM and DOM4J ?

since both Configuration and *DOM* deals with XML data it is unavoidable
that there are similarities. This is not reason enough to discard Berin's

I am not allowed to vote, but here's my take on it:

 - Namespaces are orthogonal to XML: They appear in XML, C++, Java
(packages) and so on.

 - Not supporting namespaces means that the Configuration objects are not as
flexible as they could be, as we restrict the set of tree structures that
can be contained in a configuration object. There is, for example, no way to
express what Berin is trying to express.

 - I don't see the restriction as a strength. Allowing namespaces will not
make use of Configuration instances more difficult for non-namespace using
components, neither will it violate any contracts set up for the
Configuration interface. (I have much more doubt about the modifiable
configuration interfaces I've seen discussed here.)

 - I see no reason not to include namespaces. The only opposition I've seen
is that it would make Configuration too much like DOM, and I do not consider
that a point against it. The strengths of the Configurable interface, as I
see it, is that is connects with the Component Manager, the configuration
files, and the component life cycle. It provides an easy way to configure
component managers, components and sub-components via the Configurable

So if I could vote, it would be a +1.

(In fact, I'd like to extend the Configurable interface with one method:

  Node getValueAsDOM ();

Then, you can not only store Strings, ints, booleans and floats, but also
XML data in configurations.)


To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

View raw message