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/09/28 19:24:47 UTC
[Vote] Namespace support for Configuration objects
The changes would entail the following:
1) Creation of the Namespace object
2) Adding the "getNamespace()" method to Configuration
The implementation of the Namespace object would have an
interface like this:
Namespace
{
String getPrefix(); // the portion of the xmlns that is the prefix
String getURI(); // the portion of the xmlns that is the uri
String toString(); // the xmlns as it would appear in an element
boolean equalTo(); // tests namespace objects and strings
}
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Vote] Namespace support for Configuration objects
Posted by Berin Loritsch <bl...@apache.org>.
Sylvain Wallez wrote:
>
> Berin Loritsch a écrit :
> >
> > Sylvain Wallez wrote:
> > >
> > > Berin Loritsch a écrit :
> > >
> > > 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 ?
> > >
> > > DOM4J's nice interface-based design can be mapped on about anything
> > > (there are great examples in the distro), even on data structures where
> > > you cannot travel up in the hierarchy like Configuration. So what about
> > > a DOM4JConfigurable interface and two adapter classes to wrap a
> > > Configuration as a DOM4J and a DOM4J as a Configuration to ensure
> > > compatibility with existing code ?
> >
> > Can I remind everyone right now that you can't pass a DOM4J node to a
> > Configurable object? I am trying to pass child configuraiton objects
> > to Components, and I don't want to have to propose a new Configurable
> > interface called DOMConfigurable to pass Nodes. That is rediculous.
> > The addition of the Namespace class will allow me to use the _existing_
> > framework, yet solve my problem. The Namespace objects are cached, and
> > their resources are managed.
> >
> Wow, ok, ok ! I perfectly understand that. I was expressing my feeling
> that with Namespaces in Configuration, new needs will certainly appear
> that will require some of the features already present in DOM-like APIs.
> But maybe I'm wrong...
No. The same rules that apply to Configuration objects now will apply
for the forseeable future. I do not want YAD (Yet another DOM). I don't
want the ability to traverse up or down the Configuration tree. That is
also the weakness of JDOM or DOM4J as a configuration medium.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Vote] Namespace support for Configuration objects
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Berin Loritsch a écrit :
>
> Sylvain Wallez wrote:
> >
> > Berin Loritsch a écrit :
> >
> > 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 ?
> >
> > DOM4J's nice interface-based design can be mapped on about anything
> > (there are great examples in the distro), even on data structures where
> > you cannot travel up in the hierarchy like Configuration. So what about
> > a DOM4JConfigurable interface and two adapter classes to wrap a
> > Configuration as a DOM4J and a DOM4J as a Configuration to ensure
> > compatibility with existing code ?
>
> Can I remind everyone right now that you can't pass a DOM4J node to a
> Configurable object? I am trying to pass child configuraiton objects
> to Components, and I don't want to have to propose a new Configurable
> interface called DOMConfigurable to pass Nodes. That is rediculous.
> The addition of the Namespace class will allow me to use the _existing_
> framework, yet solve my problem. The Namespace objects are cached, and
> their resources are managed.
>
Wow, ok, ok ! I perfectly understand that. I was expressing my feeling
that with Namespaces in Configuration, new needs will certainly appear
that will require some of the features already present in DOM-like APIs.
But maybe I'm wrong...
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Vote] Namespace support for Configuration objects
Posted by Berin Loritsch <bl...@apache.org>.
Sylvain Wallez wrote:
>
> Berin Loritsch a écrit :
>
> 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 ?
>
> DOM4J's nice interface-based design can be mapped on about anything
> (there are great examples in the distro), even on data structures where
> you cannot travel up in the hierarchy like Configuration. So what about
> a DOM4JConfigurable interface and two adapter classes to wrap a
> Configuration as a DOM4J and a DOM4J as a Configuration to ensure
> compatibility with existing code ?
Can I remind everyone right now that you can't pass a DOM4J node to a
Configurable object? I am trying to pass child configuraiton objects
to Components, and I don't want to have to propose a new Configurable
interface called DOMConfigurable to pass Nodes. That is rediculous.
The addition of the Namespace class will allow me to use the _existing_
framework, yet solve my problem. The Namespace objects are cached, and
their resources are managed.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Vote] Namespace support for Configuration objects
Posted by Berin Loritsch <bl...@apache.org>.
Sylvain Wallez wrote:
>
> Leo Sutic a écrit :
> >
> > So if I could vote, it would be a +1.
>
> And I also agree :) Just to make it really clear : I'm not at all
> against namespaces in Configurations. It is required in some cases, and
> Berin is facing such a case. I was just wondering if the increased
> fonctionnality will not make Configuration look like a new DOM
> alternative.
I doubt it. Hopefully it is not the case. For one thing there is no way
to traverse UP the hierarchy. This is by design, and I would be adamantly
opposed to anything suggesting such a change. I do not want developers to
think of Configuration as an alternative to DOM, but I do want to provide
additional information that is expressed in the XML that cannot
currently be transferred to configuration space.
Hopefully noone will think that Configuration is a reasonable alternative
to DOM.
> > (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.)
> >
> > /LS
>
> ??? Are you talking about a Configuration->DOM converter ? That's what I
> was suggesting...
That may be possible, but I not sure that is what we want. We do have a
ConfigurationSerializer class that can serialize the configuration information
to an output stream. It technically could be adapted to generate a DOM tree,
but I am skeptical about the usefulness of such a transformation.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Vote] Namespace support for Configuration objects
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Leo Sutic a écrit :
>
> > -----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 ?
>
> Sylvain,
> 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
> suggestion.
>
> 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
> interface.
>
> So if I could vote, it would be a +1.
And I also agree :) Just to make it really clear : I'm not at all
against namespaces in Configurations. It is required in some cases, and
Berin is facing such a case. I was just wondering if the increased
fonctionnality will not make Configuration look like a new DOM
alternative.
> (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.)
>
> /LS
??? Are you talking about a Configuration->DOM converter ? That's what I
was suggesting...
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Vote] Namespace support for Configuration objects
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
> > I don't see the usefulness of making the
> > Configuration object into a DOM.
>
> And I am not suggesting this. I am suggesting, however, that the primitive
> types one can store as values should be extended with a DOM node type. The
> DOM should not be traversable via the Configuration interface.
>
> What I am talking about is a getValueAsDOM () method. It is the _value_ that
> is the DOM node. The configuration node has no children.
>
> Regarding resource usage: If you do not store any DOM nodes in the
> configuration the overhead is zero. If you do, you pay on a per-node basis.
> That price may be high, but as we both know it is rarely paid.
I still don't see what this buys you. What specific problem does this solve
that cannot be solved from the Configuration interface? I still maintain that
the costs associated with this approach outweigh the benefits.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [Vote] Namespace support for Configuration objects
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: den 1 oktober 2001 18:34
> To: Avalon Development
> Subject: Re: [Vote] Namespace support for Configuration objects
>
>
> Leo Sutic wrote:
> >
> > > I would be -1 on this. Configuration is built from SAX
> > > currently, and adding
> > > DOM nodes to the Configuration tree removes one of their main
> virtues: the
> > > fact that they consume fewer resources.
> >
> > That would only be a virtue if you have massive amounts of configuration
> > data in the system. So much, in fact, that it overwhelms any
> other category
> > of objects. I have not encountered any example of this.
>
> I still don't see the value. In a configuration tree, you have
> child configuration
> objects. You have _*A*_ value, that can be transformed into a
> simple type if
> necessary. Complex "values" are stored as child configuration
> elements--and
> nothing else. In fact, if a Configuration object has children
> AND a value, it
> is technically in error.
See below.
> I don't see the usefulness of making the
> Configuration object into a DOM.
And I am not suggesting this. I am suggesting, however, that the primitive
types one can store as values should be extended with a DOM node type. The
DOM should not be traversable via the Configuration interface.
What I am talking about is a getValueAsDOM () method. It is the _value_ that
is the DOM node. The configuration node has no children.
Regarding resource usage: If you do not store any DOM nodes in the
configuration the overhead is zero. If you do, you pay on a per-node basis.
That price may be high, but as we both know it is rarely paid.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Vote] Namespace support for Configuration objects
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
> > I would be -1 on this. Configuration is built from SAX
> > currently, and adding
> > DOM nodes to the Configuration tree removes one of their main virtues: the
> > fact that they consume fewer resources.
>
> That would only be a virtue if you have massive amounts of configuration
> data in the system. So much, in fact, that it overwhelms any other category
> of objects. I have not encountered any example of this.
I still don't see the value. In a configuration tree, you have child configuration
objects. You have _*A*_ value, that can be transformed into a simple type if
necessary. Complex "values" are stored as child configuration elements--and
nothing else. In fact, if a Configuration object has children AND a value, it
is technically in error.
> Storing DOM nodes in configurations is resource-intensive, yes, but:
>
> a) few types of configuration require massive amounts of DOM data.
Read this again: FEW types require the overhead of DOM.
> b) There is only one instance in the whole system, if it is used by the
> ExcaliburComponentManager. The CM loads the config and portions out parts of
> it to its components.
In a complex system, you can have a megabyte of configuration information--
converted to dom would be too much. Again, the benefit of a DOM node being
relatively available does not outweigh its costs.
> so the gain by using SAX over DOM is not as great.
Maybe not, but again, I don't see the usefulness of making the Configuration
object into a DOM. It is not meant to be a DOM, and I think it is a harmful
pattern in the long run.
> However, Cocoon2 has (had?) an XML compiler that transformed
> SAX->bytestream. Maybe a
>
> getValueAsCompiledXML ()
>
> or
>
> streamValue (ContentHandler ch)
>
> The configuration would then be:
>
> <myvalue>
> <avalon:xml>
> This text will be sent <b>along with the tags</b> to the
> <i>ContentHandler</i>
> below.
> </avalon:xml>
> </myvalue>
This would be ILLEGAL according to the contracts we have set up for
Configuration elements. You should not mix VALUE and CHILD ELEMENTS
in the same PARENT ELEMENT. This is a bad pattern, is not predictable
regarding whitespace, and in the end is not desired.
If you want that value expressed in Avalon as is, it would have to be
changed to one of the following:
<myvalue>
<avalon:xml>
<![CDATA[
This text will be sent <b>along with the tags</b> to the
<i>ContentHandler</i>
]]>
</avalon:xml>
</myvalue>
- or -
<myvalue>
<avalon:xml>
This text will be sent <b>along with the tags</b> to the
<i>ContentHandler</i>
</avalon:xml>
</myvalue>
>
> Now:
>
> Configuration config = ...
>
> Configuration myvalue = config.getChild ("myvalue");
>
> myValue.stream (ch); // Fires startDocument, characters, startElement (b),
> characters,
> // endElement (b), characters, startElement (i), characters, ...
Correction:
now String myValue = config.getChild ("myvalue.xml");
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [Vote] Namespace support for Configuration objects
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: den 1 oktober 2001 16:34
> To: Avalon Development
> Subject: Re: [Vote] Namespace support for Configuration objects
>
>
> >
> > (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.)
>
> I would be -1 on this. Configuration is built from SAX
> currently, and adding
> DOM nodes to the Configuration tree removes one of their main virtues: the
> fact that they consume fewer resources.
That would only be a virtue if you have massive amounts of configuration
data in the system. So much, in fact, that it overwhelms any other category
of objects. I have not encountered any example of this.
Storing DOM nodes in configurations is resource-intensive, yes, but:
a) few types of configuration require massive amounts of DOM data.
b) There is only one instance in the whole system, if it is used by the
ExcaliburComponentManager. The CM loads the config and portions out parts of
it to its components.
so the gain by using SAX over DOM is not as great.
However, Cocoon2 has (had?) an XML compiler that transformed
SAX->bytestream. Maybe a
getValueAsCompiledXML ()
or
streamValue (ContentHandler ch)
The configuration would then be:
<myvalue>
<avalon:xml>
This text will be sent <b>along with the tags</b> to the
<i>ContentHandler</i>
below.
</avalon:xml>
</myvalue>
Now:
Configuration config = ...
Configuration myvalue = config.getChild ("myvalue");
myValue.stream (ch); // Fires startDocument, characters, startElement (b),
characters,
// endElement (b), characters, startElement (i), characters, ...
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Vote] Namespace support for Configuration objects
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
> > -----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 ?
>
> Sylvain,
> 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
> suggestion.
>
> 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
> interface.
>
> So if I could vote, it would be a +1.
Well argued, and explained.
>
> (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.)
I would be -1 on this. Configuration is built from SAX currently, and adding
DOM nodes to the Configuration tree removes one of their main virtues: the
fact that they consume fewer resources.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [Vote] Namespace support for Configuration objects
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----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 ?
Sylvain,
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
suggestion.
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
interface.
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.)
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Vote] Namespace support for Configuration objects
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Berin Loritsch a écrit :
>
> Peter Donald wrote:
> >
> > On Sat, 29 Sep 2001 03:24, Berin Loritsch wrote:
> > > The changes would entail the following:
> > >
> > > 1) Creation of the Namespace object
> > > 2) Adding the "getNamespace()" method to Configuration
> > >
> > > The implementation of the Namespace object would have an
> > > interface like this:
> > >
> > > Namespace
> > > {
> > > String getPrefix(); // the portion of the xmlns that is the prefix
> > > String getURI(); // the portion of the xmlns that is the uri
> > > String toString(); // the xmlns as it would appear in an element
> > > boolean equalTo(); // tests namespace objects and strings
> > > }
> >
> > While I actually like the feature (I remember near begging for it at one
> > stage) I am a bit cautious about how it is planned to be used. Could you give
> > a usecase so I can be comforted to know your not using it to process data -
> > which would be better served by dom4j, jdom or similar ;)
>
> First of all, I don't like DOM APIs. Anyway, I will be using it to
> register a type mapping. A type mapping in Apache Axis is one that maps
> a schema (or primitive type) to a serializer component.
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 ?
DOM4J's nice interface-based design can be mapped on about anything
(there are great examples in the distro), even on data structures where
you cannot travel up in the hierarchy like Configuration. So what about
a DOM4JConfigurable interface and two adapter classes to wrap a
Configuration as a DOM4J and a DOM4J as a Configuration to ensure
compatibility with existing code ?
Just my .02 euro...
> Therefore, I need the ability to read the namespace data for that purpose.
> In the future, WSDD will be introduced, requiring the schema to be in
> a specific namespace, and embedding portions of a WSDL document inside
> of it. Each of these will require determining the namespaces involved.
>
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Vote] Namespace support for Configuration objects
Posted by Peter Donald <do...@apache.org>.
On Mon, 1 Oct 2001 22:43, Berin Loritsch wrote:
> Peter Donald wrote:
> > On Sat, 29 Sep 2001 03:24, Berin Loritsch wrote:
> > > The changes would entail the following:
> > >
> > > 1) Creation of the Namespace object
> > > 2) Adding the "getNamespace()" method to Configuration
> > >
> > > The implementation of the Namespace object would have an
> > > interface like this:
> > >
> > > Namespace
> > > {
> > > String getPrefix(); // the portion of the xmlns that is the prefix
> > > String getURI(); // the portion of the xmlns that is the uri
> > > String toString(); // the xmlns as it would appear in an element
> > > boolean equalTo(); // tests namespace objects and strings
> > > }
> >
> > While I actually like the feature (I remember near begging for it at one
> > stage) I am a bit cautious about how it is planned to be used. Could you
> > give a usecase so I can be comforted to know your not using it to process
> > data - which would be better served by dom4j, jdom or similar ;)
>
> First of all, I don't like DOM APIs.
Not all DOM APIs are alike ;) Actually JDOM beta4 was almost identical to our
current COnfiguration with the exception of being writeable and using
Collections classes rather than arrays. (Though they removed all type safe
getFooAsInteger() in next iteration).
> Anyway, I will be using it to
> register a type mapping. A type mapping in Apache Axis is one that maps
> a schema (or primitive type) to a serializer component.
>
> Therefore, I need the ability to read the namespace data for that purpose.
> In the future, WSDD will be introduced, requiring the schema to be in
> a specific namespace, and embedding portions of a WSDL document inside
> of it. Each of these will require determining the namespaces involved.
seems reasonable +1
considering I have near begged for namespace support in past that was an easy
+1 ;)
--
Cheers,
Pete
*------------------------------------------------*
| You can't wake a person who is pretending |
| to be asleep. -Navajo Proverb. |
*------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Vote] Namespace support for Configuration objects
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> On Sat, 29 Sep 2001 03:24, Berin Loritsch wrote:
> > The changes would entail the following:
> >
> > 1) Creation of the Namespace object
> > 2) Adding the "getNamespace()" method to Configuration
> >
> > The implementation of the Namespace object would have an
> > interface like this:
> >
> > Namespace
> > {
> > String getPrefix(); // the portion of the xmlns that is the prefix
> > String getURI(); // the portion of the xmlns that is the uri
> > String toString(); // the xmlns as it would appear in an element
> > boolean equalTo(); // tests namespace objects and strings
> > }
>
> While I actually like the feature (I remember near begging for it at one
> stage) I am a bit cautious about how it is planned to be used. Could you give
> a usecase so I can be comforted to know your not using it to process data -
> which would be better served by dom4j, jdom or similar ;)
First of all, I don't like DOM APIs. Anyway, I will be using it to
register a type mapping. A type mapping in Apache Axis is one that maps
a schema (or primitive type) to a serializer component.
Therefore, I need the ability to read the namespace data for that purpose.
In the future, WSDD will be introduced, requiring the schema to be in
a specific namespace, and embedding portions of a WSDL document inside
of it. Each of these will require determining the namespaces involved.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Vote] Namespace support for Configuration objects
Posted by Peter Donald <do...@apache.org>.
On Sat, 29 Sep 2001 03:24, Berin Loritsch wrote:
> The changes would entail the following:
>
> 1) Creation of the Namespace object
> 2) Adding the "getNamespace()" method to Configuration
>
> The implementation of the Namespace object would have an
> interface like this:
>
> Namespace
> {
> String getPrefix(); // the portion of the xmlns that is the prefix
> String getURI(); // the portion of the xmlns that is the uri
> String toString(); // the xmlns as it would appear in an element
> boolean equalTo(); // tests namespace objects and strings
> }
While I actually like the feature (I remember near begging for it at one
stage) I am a bit cautious about how it is planned to be used. Could you give
a usecase so I can be comforted to know your not using it to process data -
which would be better served by dom4j, jdom or similar ;)
--
Cheers,
Pete
---------------------------------------------------
For every complex problem there is a solution that
is simple, neat and wrong
---------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Vote] Namespace support for Configuration objects
Posted by Berin Loritsch <bl...@apache.org>.
Peter Royal wrote:
>
> At 01:24 PM 9/28/2001 -0400, you wrote:
> > boolean equalTo(); // tests namespace objects and strings
>
> i'm going to guess you're talking about overriding the standard equals()?
Oops. Yes that's what I meant to do.
>
> otherwise looks good out here in the peanut gallery.
> -pete
>
> --
> peter royal -> proyal@managingpartners.com
> managing partners, inc. -> http://www.managingpartners.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Vote] Namespace support for Configuration objects
Posted by Peter Royal <pr...@managingpartners.com>.
At 01:24 PM 9/28/2001 -0400, you wrote:
> boolean equalTo(); // tests namespace objects and strings
i'm going to guess you're talking about overriding the standard equals()?
otherwise looks good out here in the peanut gallery.
-pete
--
peter royal -> proyal@managingpartners.com
managing partners, inc. -> http://www.managingpartners.com
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org