Jeff Turner wrote:
>
> On Mon, Nov 12, 2001 at 06:19:39PM +1100, Peter Donald wrote:
> > On Sun, 11 Nov 2001 16:46, Jeff Turner wrote:
> > > Was thinking.. the namespace prefix (the foo in xmlns:foo="..") is just
> > > a convenient XML-specific notation by which a namespace URI can be
> > > associated with elements.
> > >
> > > So why do we want to expose it to users through Namespace.getPrefix()?
> >
> > I have a use case - not valid XML usage though ;) Basically in Ant2 we were
> > talking about basing decisions around namespace prefix (but completely
> > ignoring the URI part). Not sure if this is a good idea as such ... ;)
>
> It sounds.. ick :) But I'm sure you know what you're doing.
>
> Sooo..
>
> - Pete want to do weird stuff with Ant
:/ We need to be standard. We should decide the best approach.
> - Berin wants to parse WSDL, hence needs namespaces
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.
This allows a fully validatable configuration scheme. Very important.
> - Leo Sutic wants a getValueAsDOM()
Not going to happen. -1 for all the reasons I meantioned before.
> - Some people apparently want read-write access
This needs to be handled in a maneagable process. It is clear that there are
cases where a Component's configuration can change to bring it back to the
runtime state. For example, in Axis, new services can be added during the
runtime of the server. If the new services are to be available again after
restarting the configuration, we need to be able to persist the changes in
some manner.
We have not come to an elegant solution on this yet.
> - I want to add XHTML nodes (mixed content)
Not going to happen. -1 as well.
The issue here is that Configuration elements are to be simple. You CANNOT
have a simple scheme with mixed content. It adds more complexity than is
IMO necessary or desired for the purpose of CONFIGURATION!
If you want to express XHTML then use one of the many DOMs available.
JDOM, DOM4J, W3C DOM, etc.
>
> Perhaps it's time to subclass Configuration?
No, we simply need to declare our contracts that we are willing to support,
Apply KISS methodology (KEEP IT SIMPLE, STUPID), and make people use tools
that better work for their needs.
> Then maybe not.. I'm only suggesting it because adding Namespace support
> is proving surprisingly difficult.
It's because we all have different concepts of what a namespace is.
> > > Furthermore, Configuration is an interface, but Namespace is a final
> > > class. To implement any non-XML Configuration implementation will
> > > require hauling along this fully useless (outside the context of XML)
> > > Namespace class.
> >
> > Not sure what you mean. Can you qualify? What case would there be where you
> > would want to extend Namespace ?
>
> Imagine I want to implement a Configuration built from a JNDI tree,
> rather than an XML file (yes, I really do at some stage).
>
> Say I'm in the JNDI context
> "dc=myComponent,dc=myProgram,dc=myCompany,dc=net,dc=au". It makes
> perfect sense for getNamespace() to return that string, since a JNDI
> "context" is basically a namespace.
>
> However, my JNDI namespace has no notion of a "prefix". All it has is
> that string, a URI, which can be written as "jndi://dc=myCompnent,...".
>
> So in order to support this level of generality, I think Namespace
> should be an interface that has only two methods:
>
> public String getURI();
> public boolean equals(Object o);
This is reasonable. However, it can also be expressed be removing the
Namespace object, and changing the Configuration object to do this:
interface Configuration {
//.....
String getNamespace();
//.....
}
And hense, we have what we all _really_ need.
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
