You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/11/12 15:47:40 UTC
Summary of issues Avalon Framework 4.1
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Summary of issues Avalon Framework 4.1
Posted by Peter Donald <do...@apache.org>.
On Tue, 13 Nov 2001 07:34, Peter Donald wrote:
> > 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.
>
> ahhh .. Now I understand the motivation for this change! ;) works for me.
>
> > 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.
>
> I could live with that I think. So under ant the namespace string will
> return the prefix. If Configuration was sucked from LDAP then it would
> include the "dc=some,dc=domain,dc=name,dc=org". However the standard format
> will be to include the http://jakarta.apache.org/cocoon/MyDTD_v1.0
Actually now I am back to not understanding ;)
Namesapce doesn't designate location of document but "location" of schema.
Where "location" just means a URI-like construct which may or may not be an
actually location. The schema referred to is implementation dependent - LDAP
directory Schemas vs XML Schema vs DTDs vs some rule based validation system
vs programatic validation (ala Ant).
So the question is now - how do we associate this string with the particular
schema technology? ie how do we know a URI designates an XSchema or a DTD or
an LDAP schem or whatever ?
--
Cheers,
Pete
*------------------------------------------------*
| Trying is the first step to failure. |
| So never try, Lisa - Homer Jay Simpson |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Summary of issues Avalon Framework 4.1
Posted by Peter Donald <do...@apache.org>.
On Tue, 13 Nov 2001 01:47, Berin Loritsch wrote:
> 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.
ahhh .. Now I understand the motivation for this change! ;) works for me.
> 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.
I could live with that I think. So under ant the namespace string will return
the prefix. If Configuration was sucked from LDAP then it would include the
"dc=some,dc=domain,dc=name,dc=org". However the standard format will be to
include the http://jakarta.apache.org/cocoon/MyDTD_v1.0
I could work with that. It may be nice to make SAX handler easily
subclassable by making
String getNamespace( String prefix, String uri )
{
}
overideable in subclasses.
> 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.
--
Cheers,
Pete
--------------------------------------------------
The fact that nobody understands you doesn't
mean you're an artist.
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Summary of issues Avalon Framework 4.1
Posted by Jeff Turner <je...@socialchange.net.au>.
On Mon, Nov 12, 2001 at 09:47:40AM -0500, Berin Loritsch wrote:
[..]
>
> Namespace != location. The Namespace should be
> used to point to a validation class or schema of
> some sort.
[and in another mail]
> Namespaces also open up wonderful methods of expression. For instance,
> when the whole ComponentManager framework can be redone so as not needing
> a RoleManager. Examine this possibility:
>
> <datasource:jdbc xmlns:datasource="resource://org/apache/avalon/excalibur/datasource/datasource.xsd">
> <pool-controller min="2" max="10"/>
> </datasource>
>
> The schema would provide the proper default values for class="", etc.
Only the ConfigurationBuilder cares about that xmlns:datasource attribute. The
ConfigurationBuilder might use it to create a RoleManager, but the app using
the Configuration doesn't care. Therefore, shouldn't the ConfigurationBuilder
swallow the attribute?
--Jeff
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>