avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Summary of issues Avalon Framework 4.1
Date Mon, 12 Nov 2001 14:47:40 GMT
Right now, the changes to the Logging part of Avalon
are accepted, and no issues have been voiced.

However, the Namespace incorporation has proven to
be _very_ difficult.  The reason being is trying
to get everyone's oppinions to come together.  We
have not been able to do this yet.  Let me start
by declaring the current contracts surrounding the
Configuration element, and how namespaces will
extend that contract.

Configuration
-------------
* Read-Only
* Represents structured heirarchy
* Configuration != XML
* Simple interface and usage by default


Adding namespaces to the system will require one
additional string, as the Namespace URI should be
the differentiating piece of information.

Namespace != location.  The Namespace should be
used to point to a validation class or schema of
some sort.  This allows us to support fully validatable
configuration trees.  This will be a future requirement,
but it should be the desired purpose.

We already have a Location string that is used to record
the URI of the source and possibly the line number in the
file.


Therefore, I propose we do away with the Namespace class
itself, and merely represent the Namespace with a String
showing the URI to a validation/proposed validation source.

Lastly, we should NOT support attributes with a different
namespace than the parent element.  This is not a clean
solution for configuration.  We CAN explore a different
solution for this type of thing (i.e. magic values are
used by the container--so the container needs to get at
the values and not propogate them.

NOTE:

We have previously discussed DOM integration, semi-structured
configurations, and namespaced attributes.  The people who
were developing Avalon at the time ALL came to the mutual
conclusion that for the purposes of CONFIGURATION, these things
would add too much complexity, to the point that the implementation
would not be worth it.  The Configuration object is designed to
be a SIMPLE, LIGHT-WEIGHT object.

-- 

"Those who would trade liberty for
 temporary security deserve neither"
                - Benjamin Franklin

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


Mime
View raw message