You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Jeff Turner <je...@socialchange.net.au> on 2001/11/11 06:46:59 UTC
Namespace implementation too XML-specific
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()?
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.
So how about making Namespace an interface, with only two methods:
String getURI();
boolean equals(Namespace ns);
Then have a class XMLNamespace which implements Namespace.
Will have a play at prototyping this now.
--Jeff
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Namespace implementation too XML-specific
Posted by Peter Donald <do...@apache.org>.
On Mon, 12 Nov 2001 22:33, Jeff Turner wrote:
> > That is the purpose of adding a getValueAsDOM. (I also remember that
> > the suggestion ended up on the scrap heap as "feature creep.")
>
> As did Peter Donald's original request for namespace support, or so it
> sounds.
yep.
--
Cheers,
Pete
----------------------------------------
"Liberty means responsibility. That is
why most men dread it." - Locke
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Namespace implementation too XML-specific
Posted by Jeff Turner <je...@socialchange.net.au>.
On Mon, Nov 12, 2001 at 11:02:53AM +0100, Leo Sutic wrote:
>
>
> > -----Original Message-----
> > From: Jeff Turner [mailto:jeff@socialchange.net.au]
> > Sent: den 12 november 2001 10:46
> > To: Avalon Developers List
> > Subject: Re: Namespace implementation too XML-specific
> >
>
> <mail:cut/>
>
> > - Leo Sutic wants a getValueAsDOM()
> > - I want to add XHTML nodes (mixed content)
>
> I think your XHTML nodes and my getValueAsDOM are quite similar. If you have
> XHTML nodes, how are you going to get them from the configuration?
I see. I was thinking of a delegation model, with nested
ContentHandlers. When it is somehow determined that we've hit an XHTML
node, the ContentHandler that builds DOMs/JDOMs/whatever is triggered.
In jakarta-commons, there's a project called Latka that does exactly
this. It works pretty nicely.
> That is the purpose of adding a getValueAsDOM. (I also remember that
> the suggestion ended up on the scrap heap as "feature creep.")
As did Peter Donald's original request for namespace support, or so it
sounds.
> > Perhaps it's time to subclass Configuration?
> >
> > NamespaceConfiguration
> > AntNamespaceConfiguration
> > WriteableConfiguration
> > SemistructuredConfiguration
>
> Why settle for SemistructuredConfiguration: ChaoticConfiguration
Why not :)
But I meant "semistructured" in the sense Berin once used; allowing
mixed content, as opposed to "structured" where there's only elements.
--Jeff
>
> /LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Namespace implementation too XML-specific
Posted by Berin Loritsch <bl...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Namespace implementation too XML-specific
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Jeff Turner [mailto:jeff@socialchange.net.au]
> Sent: den 12 november 2001 10:46
> To: Avalon Developers List
> Subject: Re: Namespace implementation too XML-specific
>
<mail:cut/>
> - Leo Sutic wants a getValueAsDOM()
> - I want to add XHTML nodes (mixed content)
I think your XHTML nodes and my getValueAsDOM are quite similar. If you have
XHTML nodes, how are you going to get them from the configuration? That is
the purpose of adding a getValueAsDOM. (I also remember that the suggestion
ended up on the scrap heap as "feature creep.")
> Perhaps it's time to subclass Configuration?
>
> NamespaceConfiguration
> AntNamespaceConfiguration
> WriteableConfiguration
> SemistructuredConfiguration
Why settle for SemistructuredConfiguration: ChaoticConfiguration
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Namespace implementation too XML-specific
Posted by Jeff Turner <je...@socialchange.net.au>.
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
- Berin wants to parse WSDL, hence needs namespaces
- Leo Sutic wants a getValueAsDOM()
- Some people apparently want read-write access
- I want to add XHTML nodes (mixed content)
Perhaps it's time to subclass Configuration?
NamespaceConfiguration
AntNamespaceConfiguration
WriteableConfiguration
SemistructuredConfiguration
Then there could be a dom4j implementation that implements Namespace,
Writeable and Semistructured.
Then maybe not.. I'm only suggesting it because adding Namespace support
is proving surprisingly difficult.
> > 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);
--Jeff
> --
> Cheers,
>
> Pete
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Namespace implementation too XML-specific
Posted by Peter Donald <do...@apache.org>.
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 ... ;)
> 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 ?
--
Cheers,
Pete
"The perfect way is only difficult for those who pick and choose. Do not
like, do not dislike; all will then be clear. Make a hairbreadth
difference and heaven and earth are set apart; if you want the truth to
stand clear before you, never be for or against." - Bruce Lee
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>