You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Srinath Perera <he...@gmail.com> on 2004/12/09 04:53:33 UTC

[Axis2][OM] Simpler way to get NameSpace

Hi All;

l am following up the  "[Axis2] OM issues" 's improving the
OMNamespace part now we use.

OMNameSpace omNs = element.getNameSpace() ;
String nsURI = omNs.getValue();

I like to propose an improvement

a) handle OMNameSapce completly inside  the OMImpl (where the
OMnamespace is not part of OMAPI as well)
   OMElemnt{
        void registerANameSpace(String uri,String prefix);
        void registerANameSpace(String uri); //to let the parser
decide the prefix
        String getNameSpaceURI();
    }

b) some compromise, keep the OMNamespace and creating OMNamesapce as
it is. but add a getNamesapceURI() to the OMElement as the

OMNameSpace omNs = element.getNameSpace() ;
String nsURI = omNs.getValue();

is really annoying and sometime I find the return value of the
getNameSpace() is null which is impossible for valid SOAPMessage!

thoughts
Thanks
Srinath

Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi,
Sorry i did not see this mail yesterday. Here goes the answers :)

On Thu, 9 Dec 2004 21:58:57 +0600, Sanjiva Weerawarana
<sa...@opensource.lk> wrote:
> "Aleksander Slominski" <as...@cs.indiana.edu> writes:
> > XML Infoset Namespace Information Item has prefix and uri inside.
> 
> A namsespace node, which *declares* a namespace has two parts in.
> I thought we were talking about the namespace name property of an
> element .. which is just a URI.
> 
> So the OmElement needs to have three APIs:
>    - declareNamespace (OmNamespace) (I believe createNamespace should
>      be renamed to this because what its doing is declaring an NS, not
>      creating one.)
>    - String getNamespaceName ()
>    - String getNamespacePrefix ()
> 
> In addition, it would be useful to ask an element to resolve a
> prefix (for qualified values in content, for example)
>    - String resolveNamespacePrefix (String prefix)
> 
> Why do we have OmElement.resolveNamespace (uri, prefix) right now?
> What purpose does that serve?

This is used during building. Once you say resolve namespace it
returns the closest correct namespace object. it may be the
decalaration in the same element or in one of its parents. It is
actually a way of finding the namespace "object".

> 
> BTW, why does OmNamespace extend OmNode?

Just as alek said its legacy thinking. Every object in a DOM is a node ! 

> Sanjiva.
> 


-- 
Ajith Ranabahu

Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Sanjiva Weerawarana wrote:

>"Aleksander Slominski" <as...@cs.indiana.edu> writes:
>  
>
>>XML Infoset Namespace Information Item has prefix and uri inside.
>>    
>>
>
>A namsespace node, which *declares* a namespace has two parts in.
>I thought we were talking about the namespace name property of an
>element .. which is just a URI. 
>
>So the OmElement needs to have three APIs:
>    - declareNamespace (OmNamespace) (I believe createNamespace should
>      be renamed to this because what its doing is declaring an NS, not
>      creating one.)
>    - String getNamespaceName ()
>    - String getNamespacePrefix ()
>  
>
it is useful to getNamespace() so yo can use it to put into namespace 
declarations in other element, set as element or attribute namespaces ...

>In addition, it would be useful to ask an element to resolve a
>prefix (for qualified values in content, for example)
>    - String resolveNamespacePrefix (String prefix)
>
>Why do we have OmElement.resolveNamespace (uri, prefix) right now?
>What purpose does that serve?
>  
>
strange ...

>BTW, why does OmNamespace extend OmNode?
>  
>
DOM legacy ... i think it is not good design but DOM has everything 
extends Node that is super object (Element is just "syntax sugar" ...)

alek

-- 
The best way to predict the future is to invent it - Alan Kay


Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Srinath Perera <he...@gmail.com>.
On Fri, 10 Dec 2004 09:30:26 +0600, Ajith Ranabahu
<aj...@gmail.com> wrote:
> Hmm, does this mean we are dropping the OMNamespace ? (at least the interface?)
Sound like to me .. from the interface .. keep it in impl with all it
plus points!
 
> 
> 
> > +1 accepted :) I actually do not like OMNamespace no where in the API
> > (it is ok to have it in the impl hidden from the user) I was under the
> > impression that it is needed for building the OM e.g. Ajith say
> > >This is used during building. Once you say resolve namespace it
> > >returns the closest correct namespace object. it may be the
> > >decalaration in the same element or in one of its parents. It is
> > >actually a way of finding the namespace "object".
> > But we can give the prefix andnamespace Name and let the Impl resolve
> > the Namesapce object if he likes to so I am plus +1 for remove resolve
> > Namesapce
> 
> --
> Ajith Ranabahu
>

Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Ajith Ranabahu <aj...@gmail.com>.
Hmm, does this mean we are dropping the OMNamespace ? (at least the interface?)


> +1 accepted :) I actually do not like OMNamespace no where in the API
> (it is ok to have it in the impl hidden from the user) I was under the
> impression that it is needed for building the OM e.g. Ajith say
> >This is used during building. Once you say resolve namespace it
> >returns the closest correct namespace object. it may be the
> >decalaration in the same element or in one of its parents. It is
> >actually a way of finding the namespace "object".
> But we can give the prefix andnamespace Name and let the Impl resolve
> the Namesapce object if he likes to so I am plus +1 for remove resolve
> Namesapce

-- 
Ajith Ranabahu

Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Srinath Perera <he...@gmail.com>.
On Fri, 10 Dec 2004 08:46:23 +0600, Sanjiva Weerawarana
<sa...@opensource.lk> wrote:
> "Srinath Perera" <he...@gmail.com> writes:
> >
> > +1, this is what I have in my mind :) No OMNamespace for common case!
> >  shall we change  String getNamespaceName () -> String getNamespaceURI ()
> 
> No .. "namespace name" is the right name for that! I agree common
> usage is namespace URI but that's not the right term.
> 
> > > Why do we have OmElement.resolveNamespace (uri, prefix) right now?
> > > What purpose does that serve?
> > I think this is to obtain the OMNamespace object that declared with
> > (uri, prefix) pair.
> 
> Well yes :-) but what good is it? In what scenarios do you look up
> a namespace declaration when you already know the namespace name
> and prefix?
+1 accepted :) I actually do not like OMNamespace no where in the API
(it is ok to have it in the impl hidden from the user) I was under the
impression that it is needed for building the OM e.g. Ajith say
>This is used during building. Once you say resolve namespace it
>returns the closest correct namespace object. it may be the
>decalaration in the same element or in one of its parents. It is
>actually a way of finding the namespace "object".
But we can give the prefix andnamespace Name and let the Impl resolve
the Namesapce object if he likes to so I am plus +1 for remove resolve
Namesapce

Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
"Srinath Perera" <he...@gmail.com> writes:
>
> +1, this is what I have in my mind :) No OMNamespace for common case!
>  shall we change  String getNamespaceName () -> String getNamespaceURI ()

No .. "namespace name" is the right name for that! I agree common
usage is namespace URI but that's not the right term.
 
> > Why do we have OmElement.resolveNamespace (uri, prefix) right now?
> > What purpose does that serve?
> I think this is to obtain the OMNamespace object that declared with 
> (uri, prefix) pair.

Well yes :-) but what good is it? In what scenarios do you look up
a namespace declaration when you already know the namespace name
and prefix?

> +1 to remove the extension , we can not call 90% of the OMNaode
> methods on OMNamespace [now OMNamespaceImpl extends OMNodeImpl and I
> am not sure what should the setNextSibing() .... ect  suppose to do in
> OMNameSpace??? at worst those method should throw unsupported
> operation exception]

I'd prefer to remove the extension.

Sanjiva.


Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Srinath Perera <he...@gmail.com>.
On Thu, 9 Dec 2004 21:58:57 +0600, Sanjiva Weerawarana
<sa...@opensource.lk> wrote:
> "Aleksander Slominski" <as...@cs.indiana.edu> writes:
> > XML Infoset Namespace Information Item has prefix and uri inside.
> 
> A namsespace node, which *declares* a namespace has two parts in.
> I thought we were talking about the namespace name property of an
> element .. which is just a URI.
> 
> So the OmElement needs to have three APIs:
>     - declareNamespace (OmNamespace) (I believe createNamespace should
>       be renamed to this because what its doing is declaring an NS, not
>       creating one.)
>     - String getNamespaceName ()
>     - String getNamespacePrefix ()
+1, this is what I have in my mind :) No OMNamespace for common case!
 shall we change  String getNamespaceName () -> String getNamespaceURI ()

> In addition, it would be useful to ask an element to resolve a
> prefix (for qualified values in content, for example)
>     - String resolveNamespacePrefix (String prefix)
> 
> Why do we have OmElement.resolveNamespace (uri, prefix) right now?
> What purpose does that serve?
I think this is to obtain the OMNamespace object that declared with 
(uri, prefix) pair.

> BTW, why does OmNamespace extend OmNode?
+1 to remove the extension , we can not call 90% of the OMNaode
methods on OMNamespace [now OMNamespaceImpl extends OMNodeImpl and I
am not sure what should the setNextSibing() .... ect  suppose to do in
OMNameSpace??? at worst those method should throw unsupported
operation exception]

Thanks
Srinath

Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
"Aleksander Slominski" <as...@cs.indiana.edu> writes:
> XML Infoset Namespace Information Item has prefix and uri inside.

A namsespace node, which *declares* a namespace has two parts in.
I thought we were talking about the namespace name property of an
element .. which is just a URI. 

So the OmElement needs to have three APIs:
    - declareNamespace (OmNamespace) (I believe createNamespace should
      be renamed to this because what its doing is declaring an NS, not
      creating one.)
    - String getNamespaceName ()
    - String getNamespacePrefix ()

In addition, it would be useful to ask an element to resolve a
prefix (for qualified values in content, for example)
    - String resolveNamespacePrefix (String prefix)

Why do we have OmElement.resolveNamespace (uri, prefix) right now?
What purpose does that serve?

BTW, why does OmNamespace extend OmNode?

Sanjiva.

Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Sanjiva Weerawarana wrote:

>"Aleksander Slominski" <as...@cs.indiana.edu> writes:
>  
>
>>well i think using namespace as String is not the best way. much better 
>>is OmNamespace immutable object that can be shared and passed around and 
>>compared with other namespaces. so this means code is OmNamespace = 
>>el.getNamespace() - which is as simple as it gets (and type safe too ...)
>>    
>>
>
>So is it the case that OmNamespace has *ONLY* an NSURI string in it?
>(SVN is down right now so can't get the latest code to check.)
>
>If yes then you can of course compare strings using == too and get
>the same return - just intern the NSURI strings. If the namespace
>has the prefix then its broken of course .. two namespace names can
>be the same with different prefixes assigned to them.
>
>It seems that Srinath's suggestion will be a simpler solution ??
>
>  
>
XML Infoset Namespace Information Item has prefix and uri inside.


>>which is exactly the same argument as for QName value object ...
>>    
>>
>
>??? QName is a name with two parts .. so you have to have an object.
>  
>
XML Infoset Namespace has also two parts.

alek

-- 
The best way to predict the future is to invent it - Alan Kay


Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
"Aleksander Slominski" <as...@cs.indiana.edu> writes:
> >
> well i think using namespace as String is not the best way. much better 
> is OmNamespace immutable object that can be shared and passed around and 
> compared with other namespaces. so this means code is OmNamespace = 
> el.getNamespace() - which is as simple as it gets (and type safe too ...)

So is it the case that OmNamespace has *ONLY* an NSURI string in it?
(SVN is down right now so can't get the latest code to check.)

If yes then you can of course compare strings using == too and get
the same return - just intern the NSURI strings. If the namespace
has the prefix then its broken of course .. two namespace names can
be the same with different prefixes assigned to them.

It seems that Srinath's suggestion will be a simpler solution ??

> which is exactly the same argument as for QName value object ...

??? QName is a name with two parts .. so you have to have an object.

Sanjiva.


Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Srinath Perera wrote:

>>>But alek wrting two lines where when u need one all cases (with DOM
>>>ect ) is what I do not like. this is one of THE MOST COMMONLY called
>>>methods in the OM!
>>>
>>>
>>>      
>>>
>>you can write it in one line: element.getNamespace().getNamespaceName() :)
>>    
>>
>
>that is a argument that can use to justify almosr anything :) ,if that
>is reasonable argument I can keep generating similer arguments for
>almost anything ;)
>  
>
well i think using namespace as String is not the best way. much better 
is OmNamespace immutable object that can be shared and passed around and 
compared with other namespaces. so this means code is OmNamespace = 
el.getNamespace() - which is as simple as it gets (and type safe too ...)

which is exactly the same argument as for QName value object ...

alek

>Thanks
>Srinath
>
>
>On Thu, 09 Dec 2004 00:11:10 -0500, Aleksander Slominski
><as...@cs.indiana.edu> wrote:
>  
>
>>Srinath Perera wrote:
>>
>>
>>
>>    
>>
>>>Hi Alek
>>>
>>>On Wed, 08 Dec 2004 23:04:32 -0500, Aleksander Slominski
>>><as...@cs.indiana.edu> wrote:
>>>
>>>
>>>      
>>>
>>>>Srinath Perera wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>Hi All;
>>>>>
>>>>>l am following up the  "[Axis2] OM issues" 's improving the
>>>>>OMNamespace part now we use.
>>>>>
>>>>>OMNameSpace omNs = element.getNameSpace() ;
>>>>>String nsURI = omNs.getValue();
>>>>>
>>>>>I like to propose an improvement
>>>>>
>>>>>a) handle OMNameSapce completly inside  the OMImpl (where the
>>>>>OMnamespace is not part of OMAPI as well)
>>>>> OMElemnt{
>>>>>      void registerANameSpace(String uri,String prefix);
>>>>>      void registerANameSpace(String uri); //to let the parser
>>>>>decide the prefix
>>>>>      String getNameSpaceURI();
>>>>>  }
>>>>>
>>>>>b) some compromise, keep the OMNamespace and creating OMNamesapce as
>>>>>it is. but add a getNamesapceURI() to the OMElement as the
>>>>>
>>>>>OMNameSpace omNs = element.getNameSpace() ;
>>>>>String nsURI = omNs.getValue();
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>IMHO OmNamespace should be immutable object with just two properties:
>>>>namespace name (String) that is always not null and prefix (String) that
>>>>can be null - that would keep it consistent with xml infoset items and
>>>>properties: http://www.w3.org/TR/xml-infoset/#infoitem.namespace
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>is really annoying and sometime I find the return value of the
>>>>>getNameSpace() is null which is impossible for valid SOAPMessage!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>so it should never return it and if it does you have simple NPE to find
>>>>where it happened...
>>>>
>>>>
>>>>        
>>>>
>>>But alek wrting two lines where when u need one all cases (with DOM
>>>ect ) is what I do not like. this is one of THE MOST COMMONLY called
>>>methods in the OM!
>>>
>>>
>>>      
>>>
>>you can write it in one line: element.getNamespace().getNamespaceName() :)
>>
>>alek
>>
>>    
>>
>>>      
>>>
>>>>--
>>>>The best way to predict the future is to invent it - Alan Kay
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>--
>>
>>
>>The best way to predict the future is to invent it - Alan Kay
>>
>>
>>    
>>


-- 
The best way to predict the future is to invent it - Alan Kay


Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Srinath Perera <he...@gmail.com>.
> >But alek wrting two lines where when u need one all cases (with DOM
> >ect ) is what I do not like. this is one of THE MOST COMMONLY called
> >methods in the OM!
> >
> >
> you can write it in one line: element.getNamespace().getNamespaceName() :)

that is a argument that can use to justify almosr anything :) ,if that
is reasonable argument I can keep generating similer arguments for
almost anything ;)
Thanks
Srinath


On Thu, 09 Dec 2004 00:11:10 -0500, Aleksander Slominski
<as...@cs.indiana.edu> wrote:
> Srinath Perera wrote:
> 
> 
> 
> >Hi Alek
> >
> >On Wed, 08 Dec 2004 23:04:32 -0500, Aleksander Slominski
> ><as...@cs.indiana.edu> wrote:
> >
> >
> >>Srinath Perera wrote:
> >>
> >>
> >>
> >>
> >>
> >>>Hi All;
> >>>
> >>>l am following up the  "[Axis2] OM issues" 's improving the
> >>>OMNamespace part now we use.
> >>>
> >>>OMNameSpace omNs = element.getNameSpace() ;
> >>>String nsURI = omNs.getValue();
> >>>
> >>>I like to propose an improvement
> >>>
> >>>a) handle OMNameSapce completly inside  the OMImpl (where the
> >>>OMnamespace is not part of OMAPI as well)
> >>>  OMElemnt{
> >>>       void registerANameSpace(String uri,String prefix);
> >>>       void registerANameSpace(String uri); //to let the parser
> >>>decide the prefix
> >>>       String getNameSpaceURI();
> >>>   }
> >>>
> >>>b) some compromise, keep the OMNamespace and creating OMNamesapce as
> >>>it is. but add a getNamesapceURI() to the OMElement as the
> >>>
> >>>OMNameSpace omNs = element.getNameSpace() ;
> >>>String nsURI = omNs.getValue();
> >>>
> >>>
> >>>
> >>>
> >>IMHO OmNamespace should be immutable object with just two properties:
> >>namespace name (String) that is always not null and prefix (String) that
> >>can be null - that would keep it consistent with xml infoset items and
> >>properties: http://www.w3.org/TR/xml-infoset/#infoitem.namespace
> >>
> >>
> >>
> >>>is really annoying and sometime I find the return value of the
> >>>getNameSpace() is null which is impossible for valid SOAPMessage!
> >>>
> >>>
> >>>
> >>>
> >>so it should never return it and if it does you have simple NPE to find
> >>where it happened...
> >>
> >>
> >But alek wrting two lines where when u need one all cases (with DOM
> >ect ) is what I do not like. this is one of THE MOST COMMONLY called
> >methods in the OM!
> >
> >
> you can write it in one line: element.getNamespace().getNamespaceName() :)
> 
> alek
> 
> >
> >
> >>--
> >>The best way to predict the future is to invent it - Alan Kay
> >>
> >>
> >>
> >>
> 
> 
> --
> 
> 
> The best way to predict the future is to invent it - Alan Kay
> 
>

Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Srinath Perera wrote:

>Hi Alek
>
>On Wed, 08 Dec 2004 23:04:32 -0500, Aleksander Slominski
><as...@cs.indiana.edu> wrote:
>  
>
>>Srinath Perera wrote:
>>
>>
>>
>>    
>>
>>>Hi All;
>>>
>>>l am following up the  "[Axis2] OM issues" 's improving the
>>>OMNamespace part now we use.
>>>
>>>OMNameSpace omNs = element.getNameSpace() ;
>>>String nsURI = omNs.getValue();
>>>
>>>I like to propose an improvement
>>>
>>>a) handle OMNameSapce completly inside  the OMImpl (where the
>>>OMnamespace is not part of OMAPI as well)
>>>  OMElemnt{
>>>       void registerANameSpace(String uri,String prefix);
>>>       void registerANameSpace(String uri); //to let the parser
>>>decide the prefix
>>>       String getNameSpaceURI();
>>>   }
>>>
>>>b) some compromise, keep the OMNamespace and creating OMNamesapce as
>>>it is. but add a getNamesapceURI() to the OMElement as the
>>>
>>>OMNameSpace omNs = element.getNameSpace() ;
>>>String nsURI = omNs.getValue();
>>>
>>>
>>>      
>>>
>>IMHO OmNamespace should be immutable object with just two properties:
>>namespace name (String) that is always not null and prefix (String) that
>>can be null - that would keep it consistent with xml infoset items and
>>properties: http://www.w3.org/TR/xml-infoset/#infoitem.namespace
>>
>>    
>>
>>>is really annoying and sometime I find the return value of the
>>>getNameSpace() is null which is impossible for valid SOAPMessage!
>>>
>>>
>>>      
>>>
>>so it should never return it and if it does you have simple NPE to find
>>where it happened...
>>    
>>
>But alek wrting two lines where when u need one all cases (with DOM
>ect ) is what I do not like. this is one of THE MOST COMMONLY called
>methods in the OM!
>  
>
you can write it in one line: element.getNamespace().getNamespaceName() :)

alek

>  
>
>>--
>>The best way to predict the future is to invent it - Alan Kay
>>
>>
>>    
>>


-- 
The best way to predict the future is to invent it - Alan Kay


Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Srinath Perera <he...@gmail.com>.
Hi Alek

On Wed, 08 Dec 2004 23:04:32 -0500, Aleksander Slominski
<as...@cs.indiana.edu> wrote:
> Srinath Perera wrote:
> 
> 
> 
> >Hi All;
> >
> >l am following up the  "[Axis2] OM issues" 's improving the
> >OMNamespace part now we use.
> >
> >OMNameSpace omNs = element.getNameSpace() ;
> >String nsURI = omNs.getValue();
> >
> >I like to propose an improvement
> >
> >a) handle OMNameSapce completly inside  the OMImpl (where the
> >OMnamespace is not part of OMAPI as well)
> >   OMElemnt{
> >        void registerANameSpace(String uri,String prefix);
> >        void registerANameSpace(String uri); //to let the parser
> >decide the prefix
> >        String getNameSpaceURI();
> >    }
> >
> >b) some compromise, keep the OMNamespace and creating OMNamesapce as
> >it is. but add a getNamesapceURI() to the OMElement as the
> >
> >OMNameSpace omNs = element.getNameSpace() ;
> >String nsURI = omNs.getValue();
> >
> >
> IMHO OmNamespace should be immutable object with just two properties:
> namespace name (String) that is always not null and prefix (String) that
> can be null - that would keep it consistent with xml infoset items and
> properties: http://www.w3.org/TR/xml-infoset/#infoitem.namespace
> 
> >is really annoying and sometime I find the return value of the
> >getNameSpace() is null which is impossible for valid SOAPMessage!
> >
> >
> so it should never return it and if it does you have simple NPE to find
> where it happened...
But alek wrting two lines where when u need one all cases (with DOM
ect ) is what I do not like. this is one of THE MOST COMMONLY called
methods in the OM!

> 
> --
> The best way to predict the future is to invent it - Alan Kay
> 
>

Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Srinath Perera wrote:

>Hi All;
>
>l am following up the  "[Axis2] OM issues" 's improving the
>OMNamespace part now we use.
>
>OMNameSpace omNs = element.getNameSpace() ;
>String nsURI = omNs.getValue();
>
>I like to propose an improvement
>
>a) handle OMNameSapce completly inside  the OMImpl (where the
>OMnamespace is not part of OMAPI as well)
>   OMElemnt{
>        void registerANameSpace(String uri,String prefix);
>        void registerANameSpace(String uri); //to let the parser
>decide the prefix
>        String getNameSpaceURI();
>    }
>
>b) some compromise, keep the OMNamespace and creating OMNamesapce as
>it is. but add a getNamesapceURI() to the OMElement as the
>
>OMNameSpace omNs = element.getNameSpace() ;
>String nsURI = omNs.getValue();
>  
>
IMHO OmNamespace should be immutable object with just two properties: 
namespace name (String) that is always not null and prefix (String) that 
can be null - that would keep it consistent with xml infoset items and 
properties: http://www.w3.org/TR/xml-infoset/#infoitem.namespace

>is really annoying and sometime I find the return value of the
>getNameSpace() is null which is impossible for valid SOAPMessage!
>  
>
so it should never return it and if it does you have simple NPE to find 
where it happened...

alek

-- 
The best way to predict the future is to invent it - Alan Kay


Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Srinath Perera <he...@gmail.com>.
On Fri, 10 Dec 2004 12:09:02 +0600, Eran Chinthaka
<ch...@opensource.lk> wrote:
> 
> 
> 
> 
> >>> To start with I don't that much understand why Srinath wanna remove
> >>> OMNamespace from the API and "Hide" it. Has it committed a crime ?? :)
> >>
> >>My real concern is String getNamespaceName (),  String
> >>getNamespacePrefix () method , Hiding OMNamesapce is a WISH, what do
> >>we get by keeping it and put so many methods to manipulate it?
> >>
> >>To me correct approach is to expose three things locaname, prefix and
> >>namespacename and  hide the implementation. User need not to aware
> >>about the our representation.
> 
> [Chinthaka] What is the local name for a namespace ?
> BTW, Srinath, we are hiding the impl. Yes its true. But what I say is we
> need the API to have OMNamespace interface.
let us compromise and keep the OMNamespace :)

> 
> >>
> >>Any way this is just a WISH and let drop it if people do not agree :)
> 
> >>
> >> > First I will explain the rationale behind some namespace methods in
> >>> OMElement.
> >>>
> >>>         The resolveNamespace(uri, prefix) is there to check whether
> >>there
> >>> are any namespaces already created with the given info.
> >>> The reason behind having this is that, one can avoid having two
> >>namespaces
> >>> with same uri and prefix. I think as Sanjiva suggested
> >>> resolveNamespace(prefix) should also be there.
> >>> But according to what Alek said, I agree that this should be
> >>> resolveNamespace(uri). But this means, there can be two (or more)
> >>namespace
> >>> with different prefixes, but same URI ? Do we wanna allow that ??
> >>>         The createNamespace(uri, prefix) - I agree to rename this as
> >>> declareNamespace :)
> >>
> >>
> >>> And I agree that OMNamespace must have following methods.
> >>>         - String getNamespaceName ()
> >>>         - String getNamespacePrefix ()
> >>
> >>What Dr Sanjiva Said is
> >>>So the OmElement needs to have three APIs:
> >>>   - declareNamespace (OmNamespace) (I believe createNamespace should
> >>>     be renamed to this because what its doing is declaring an NS, not
> >>>    creating one.)
> >>>   - String getNamespaceName ()
> >>>   - String getNamespacePrefix ()
> >>and above two methods are requested for OmElement !!! geting the local
> >>name and the namespace name is the 80% use case in OM and by having
> >>OMNameSapce getNameSpace() and making the user make to calls most simplest
> >>case.
> >>
> >>1) at most of the time enfine will be calling getLocalName() and
> >>getNamespaceName ()
> >>2) engine will never ask for the prefix from OM unless we go in to
> >>security and prefix does not matter for usual execution
> >>
> >>We should have simple common case clean !!!


> [Chinthaka] Agreed.
+1 we are converging :) 
> 
> 
> >>
> >>> The rationale behind OMNamespace extends OMNode is that, we store
> >>Namespaces
> >>> in the element as a linked list. I agree that this extending from some
> >>what
> >>> weird OMNode. I think the name is not correct. We want to have
> >>> getNextSibling, insertSibling etc., to OMNamespace as well.
> >>> One must agree that OMNamespace *MUST* have getNextSibling,
> >>insertSibling
> >>what is the getNextSibling() ..insertSibling() suppose to do in the
> >>OMNamespace()? One can define differant symantic for such method but
> >>other one will see it differant. Keep it clean and give one way to do
> >>the things.
> >>Let me get a example what is appoch leads to.
> >>At OMElement getValue() return a LocalName .. but the I persive it to
> >>get TextValue from get value  We should avoid put methods that have
> >>unclear symantic.. getValue must throw UnSupportedOperationException
> >>at worst.
> 
> [Chinthaka] I didn't get this well, Srinath. But let me come up with a
> better ways of having OMNamespace without extending from OMNode.
> Alek and myself started a thread on this.
cool +1

Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Srinath Perera <he...@gmail.com>.
> why not have utility method String getNamespaceName() implemented as {
> getNamespace().getName(); }?
Alek I can walk around it in quite a number of ways .. but let me do it directly

 
> >1) at most of the time enfine will be calling getLocalName() and
> >getNamespaceName ()
> >
> >
> why not have it call getQName then?
What getQName ;) I would have use it had it been there

 
> >2) engine will never ask for the prefix from OM unless we go in to
> >security and prefix does not matter for usual execution
> >
> >
> unfortunately prefixes matter even for "normal" execution if you send
> documents that have QNames in attribute values (not names) or element
> text - for example if you send WS-Addressing EPR where portType is QName ...
> http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/#_Toc77464319
> 
> for better or worse namespace prefixes *matter*
my statement changed! never = 90% of the actual usecase. My poblem is
we are making simple case hard!

Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Srinath Perera wrote:

>>To start with I don't that much understand why Srinath wanna remove
>>OMNamespace from the API and "Hide" it. Has it committed a crime ?? :)
>>    
>>
>
>My real concern is String getNamespaceName (),  String
>getNamespacePrefix () method , Hiding OMNamesapce is a WISH, what do
>we get by keeping it and put so many methods to manipulate it?
>
>To me correct approach is to expose three things locaname, prefix and
>namespacename and  hide the implementation. User need not to aware
>about the our representation.
>
>Any way this is just a WISH and let drop it if people do not agree :)
> 
> > First I will explain the rationale behind some namespace methods in
>  
>
>>OMElement.
>>
>>        The resolveNamespace(uri, prefix) is there to check whether there
>>are any namespaces already created with the given info.
>>The reason behind having this is that, one can avoid having two namespaces
>>with same uri and prefix. I think as Sanjiva suggested
>>resolveNamespace(prefix) should also be there.
>>But according to what Alek said, I agree that this should be
>>resolveNamespace(uri). But this means, there can be two (or more) namespace
>>with different prefixes, but same URI ? Do we wanna allow that ??
>>        The createNamespace(uri, prefix) - I agree to rename this as
>>declareNamespace :)
>>    
>>
>
>
>  
>
>>And I agree that OMNamespace must have following methods.
>>        - String getNamespaceName ()
>>        - String getNamespacePrefix ()
>>    
>>
>
>What Dr Sanjiva Said is 
>  
>
>>So the OmElement needs to have three APIs:
>>  - declareNamespace (OmNamespace) (I believe createNamespace should
>>    be renamed to this because what its doing is declaring an NS, not
>>   creating one.)
>>  - String getNamespaceName ()
>>  - String getNamespacePrefix ()
>>    
>>
>and above two methods are requested for OmElement !!! geting the local
>name and the namespace name is the 80% use case in OM and by having
>OMNameSapce getNameSpace() and making the user make to calls most simplest case.
>  
>
why not have utility method String getNamespaceName() implemented as { 
getNamespace().getName(); }?

>1) at most of the time enfine will be calling getLocalName() and 
>getNamespaceName ()
>  
>
why not have it call getQName then?

>2) engine will never ask for the prefix from OM unless we go in to
>security and prefix does not matter for usual execution
>  
>
unfortunately prefixes matter even for "normal" execution if you send 
documents that have QNames in attribute values (not names) or element 
text - for example if you send WS-Addressing EPR where portType is QName ...
http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/#_Toc77464319

for better or worse namespace prefixes *matter*

my .02c

thanks,

alek

>We should have simple common case clean !!!
> 
>  
>
>>The rationale behind OMNamespace extends OMNode is that, we store Namespaces
>>in the element as a linked list. I agree that this extending from some what
>>weird OMNode. I think the name is not correct. We want to have
>>getNextSibling, insertSibling etc., to OMNamespace as well.
>>One must agree that OMNamespace *MUST* have getNextSibling, insertSibling
>>    
>>
>what is the getNextSibling() ..insertSibling() suppose to do in the
>OMNamespace()? One can define differant symantic for such method but
>other one will see it differant. Keep it clean and give one way to do
>the things.
>Let me get a example what is appoch leads to. 
>At OMElement getValue() return a LocalName .. but the I persive it to
>get TextValue from get value  We should avoid put methods that have
>unclear symantic.. getValue must throw UnSupportedOperationException
>at worst.
>
>Unless someone give a better explanation I am -1 on extending
>OMNamespace from OMNode!!
> 
>Thanks
>Srinath
>  
>


-- 
The best way to predict the future is to invent it - Alan Kay


Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Srinath Perera <he...@gmail.com>.
> To start with I don't that much understand why Srinath wanna remove
> OMNamespace from the API and "Hide" it. Has it committed a crime ?? :)

My real concern is String getNamespaceName (),  String
getNamespacePrefix () method , Hiding OMNamesapce is a WISH, what do
we get by keeping it and put so many methods to manipulate it?

To me correct approach is to expose three things locaname, prefix and
namespacename and  hide the implementation. User need not to aware
about the our representation.

Any way this is just a WISH and let drop it if people do not agree :)
 
 > First I will explain the rationale behind some namespace methods in
> OMElement.
> 
>         The resolveNamespace(uri, prefix) is there to check whether there
> are any namespaces already created with the given info.
> The reason behind having this is that, one can avoid having two namespaces
> with same uri and prefix. I think as Sanjiva suggested
> resolveNamespace(prefix) should also be there.
> But according to what Alek said, I agree that this should be
> resolveNamespace(uri). But this means, there can be two (or more) namespace
> with different prefixes, but same URI ? Do we wanna allow that ??
>         The createNamespace(uri, prefix) - I agree to rename this as
> declareNamespace :)


> And I agree that OMNamespace must have following methods.
>         - String getNamespaceName ()
>         - String getNamespacePrefix ()

What Dr Sanjiva Said is 
>So the OmElement needs to have three APIs:
>   - declareNamespace (OmNamespace) (I believe createNamespace should
>     be renamed to this because what its doing is declaring an NS, not
>    creating one.)
>   - String getNamespaceName ()
>   - String getNamespacePrefix ()
and above two methods are requested for OmElement !!! geting the local
name and the namespace name is the 80% use case in OM and by having
OMNameSapce getNameSpace() and making the user make to calls most simplest case.

1) at most of the time enfine will be calling getLocalName() and 
getNamespaceName ()
2) engine will never ask for the prefix from OM unless we go in to
security and prefix does not matter for usual execution

We should have simple common case clean !!!
 
> The rationale behind OMNamespace extends OMNode is that, we store Namespaces
> in the element as a linked list. I agree that this extending from some what
> weird OMNode. I think the name is not correct. We want to have
> getNextSibling, insertSibling etc., to OMNamespace as well.
> One must agree that OMNamespace *MUST* have getNextSibling, insertSibling
what is the getNextSibling() ..insertSibling() suppose to do in the
OMNamespace()? One can define differant symantic for such method but
other one will see it differant. Keep it clean and give one way to do
the things.
Let me get a example what is appoch leads to. 
At OMElement getValue() return a LocalName .. but the I persive it to
get TextValue from get value  We should avoid put methods that have
unclear symantic.. getValue must throw UnSupportedOperationException
at worst.

Unless someone give a better explanation I am -1 on extending
OMNamespace from OMNode!!
 
Thanks
Srinath

Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Ajith Ranabahu <aj...@gmail.com>.
Ahum, Just think of it this way.
We need the resloveNamespace method to drill down to the correct
namespace *object*, which is for the humble purpose of not creating
multiple objects.
I see two views of this and here they are

bad news first :) (why we should drop namespace from interfaces or
make it a non-omnode)

1. Users can easily do without a namespace object. all you have to do
is say addNamespace and everything can be handled under the hood.
Internally we may keep a holder object (similar to the one we have
right now) but users can do without that.

2. Eventhough namspace is a node with previous and next sibling
pointers we are not using them. API does not have methods that return
an iterator of namespaces nor it has a getNamespace(int i) method
neither. So as it stands today the code can be easily made to run with
a non-OMNode namespace object.
BTW for the simple reason that there are no methods to get the list of
declared namespaces, the simpleOMSeriliazer serializes the elements
with their own namespace declaration. ugly but perfectly valid :D
.
Now the good news (why we should not drop it)
1. Users are likely to get both the uri (namespace name) and the
prefix *together* because they are related.

2. We can get away by giving an iterator for the namespaces since
namespaces are objects :)

3. we can make the namepace immutable effectively promoting
re-use.There is no apparent reason *not to* expose it if it is
immutable.

As for Erans "two-prefix-same-uri" problem here is my solution
Namespace declarations with the same URI and different prefixes can be
made to refer to a single namespace object without harming the
semantics. (this is a direct violation of the "infoset preservation"
concept though). But it can clear up the matters a lot!

As you can see I am more towrds keeping /exposing at least a simpler
namespace object :)
 
-- 
Ajith Ranabahu

Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Ajith Ranabahu <aj...@gmail.com>.
+1 to keep the Namspace object and I have no problem in giving two
more methods to access the namespace name and the prefix.

However we need to figure out how to go about with this.

1 . Are we removing the OMNode extension ? ( think we are, but if so
we need to figure out an alternating mechanism to keep the
relationship of namespaces.)

2. If we can use the constructors to inject the values and keep only
*getter* methods in the interfaces I guess most of our problems will
go away :)

-- 
Ajith Ranabahu

Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Ajith Ranabahu <aj...@gmail.com>.
Hold on a sec! Why would anyone need to search the document for all
the namespaces with a given prefix? I don't see any acceptable usecase
where the USER needs to handle such complexities.
As far as I am concerned the findnamespace method is concerned only
with the current element ! is it not? (you cant have more than one
namespace with a given prefix in that case) so that we should not
provide a lot of alternatives through a single method.


On Fri, 10 Dec 2004 12:55:56 +0600, Eran Chinthaka
<ch...@opensource.lk> wrote:
> 
> 
> 
> 
> >>
> >>Srinath Perera wrote:
> >>
> >>>>So, let me try to summarize where we are now w.r.t. namespaces:
> >>>>
> >>>>    interface OmNamespace {
> >>>>        public String getName (); // seems redundant to say
> >>>>getNamespaceName!
> >>>>        public String getPrefix ();
> >>>>    }
> >>>>
> >>>>
> >>>+1
> >>>
> >>>
> >>>
> >>>>OMElement has the following:
> >>>>
> >>>>    interface OmElement extends OmNode {
> >>>>
> >>>>
> >>why does this have to extend OmNode?
> >>
> >>>>        // declare a namespace at this element
> >>>>        public OmNamespace declareNamespace (String uri, String prefix);
> >>>>
> >>>>
> >>also declareNamespace(OmNamespace) to allow reuse of namespace
> >>declarations (perfectly fine and safe if OmNamespace is immutable)
> >>
> >>>>        // find a namespace declaration here or from parent
> >>>>        public OmNamespace findNamespace (String uri, String prefix);
> >>>>
> >>>>
> >>i guess:
> >>
> >>if prefix != null && uri != null find OmNamespace that has
> >>OmNamespace.getPrefix() == prefix && OmNamespace.getName() == uri
> >>if uri != null find OmNamespace that has OmNamespace.getName() == uri
> >>if prefix != null find OmNamespace that has OmNamespace.getPrefix() ==
> >>prefix
> >>
> >>what happens for findNamespace(null, null) ?!
> 
> [Chinthaka] I think having two methods is bit of a over doing.
> We can do the samething using one method.
> If u try to address the findNamespace(null, null) problem using two methods,
> u r in trouble again, as what if findNamespaceByPrefix(null) or
> findNamespaceByUri (null).
> 
> I think its better to have one method like
>        OmNamespace findNamespace (String uri, String prefix);
> If findNamespace(null,null), just throw an exception or return all. But if
> we want to return all there should be another method like
> Collection findNamespace (String uri, String prefix);
> 
> And there is one other problem.
> What if someone try to retrieve all the namespace which has some prefix.
> 
> Say findNamespace(null,prefix). SO this should return a collection. Or else,
> we document and say if there is more than one we just return the first one.
> 
> Comments ???
> 
> Regards
> -- Eran Chinthaka
> 
> 
> 
> >>
> >>maybe better is to have two functions?
> >>
> >>        public OmNamespace findNamespaceByPrefix (String prefix);
> >>        public OmNamespace findNamespaceByUri (String uri);
> >>
> >>
> >>>>        // get my namespace name
> >>>>        public String getNamespaceName ();
> >>>>
> >>>>        // get my local name
> >>>>        public String getLocalName ();
> >>>>
> >>>>        ..
> >>>>    }
> >>>>
> >>>>
> >>>+1 Think  we are converging :) are we ?
> >>>
> >>>
> >>looks good to me?
> >>
> >>--
> >>The best way to predict the future is to invent it - Alan Kay
> >>
> 
> 


-- 
Ajith Ranabahu

Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
"Eran Chinthaka" <ch...@opensource.lk> writes:
>
> [Chinthaka] I think having two methods is bit of a over doing.
> We can do the samething using one method.
> If u try to address the findNamespace(null, null) problem using two
methods,
> u r in trouble again, as what if findNamespaceByPrefix(null) or
> findNamespaceByUri (null).
>
> I think its better to have one method like
> OmNamespace findNamespace (String uri, String prefix);
> If findNamespace(null,null), just throw an exception or return all. But if
> we want to return all there should be another method like
> Collection findNamespace (String uri, String prefix);
>
> And there is one other problem.
> What if someone try to retrieve all the namespace which has some prefix.
>
> Say findNamespace(null,prefix). SO this should return a collection. Or
else,
> we document and say if there is more than one we just return the first
one.
>
> Comments ???

ARGH! This is getting waaay too complicated for my liking. I suggest
we just say findNamespace(uri,prefix) requires that uri!=null and
prefix!=null .. as that exists to allow one to reuse OmNamespace
nodes. If you just want to resolve a prefix or a uri then you can
use the resolveXXX methods.

Sanjiva.


Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Srinath Perera <he...@gmail.com>.
On Mon, 13 Dec 2004 14:54:36 +0600, Sanjiva Weerawarana
<sa...@opensource.lk> wrote:
> "Glen Daniels" <gl...@thoughtcraft.com> writes:
> > 3) Map namespaces at a given OMElement:
> >
> >    void registerNamespace(String uri, String prefix)
> 
> declareNamespace(.,.)?
> 
> 
> 
> > 4) Ensure that we have a consistent view on what is a namespace
> > declaration and what is an attribute.  For this XML:
> >
> >    <foo xmlns:ns1="http://ns1" attr1="bar"/>
> >
> > EITHER:
> >
> > getAttributes() returns JUST attr1, and getAllAttributes() returns both
> > the ns1 declaration and att1
> >
> > OR:
> >
> > getAttributes() returns both attributes.
> >
> > I prefer the former.  In either case I think we should consistency check
> > attributes by noticing if they are namespace declarations when they get
> > added.  After this:
> >
> >    OMAttribute attr = new OMAttribute(new QName(XMLNS, "ns1"),
> >                                       "http://ns1");
> >    element.addAttribute(attr);
> >
> > The element should now have a new namespace mapping, and our code should
> > complain if the "ns1" prefix is already mapped in this element.
> 
> So this comes down to whether the AXIOM representation is for XML 1.0
> or XML 1.0 + Namespaces. My pref would be to say that its *only* a
> namespace aware Infoset model and *never* treat namespace declarations
> as attributes.
> 
> That means, getAttribues() only returns "attr1" and we don't have
> something called getAllAttributes().
> 
> Sanjiva.
+1 yes I too not feel good about having attributes and NS mixed,
afterall we have a one way to get attributes and one way to get NS.
Why we need more than one way to get the same things?

Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Eran Chinthaka wrote:

>>>"Glen Daniels" <gl...@thoughtcraft.com> writes:
>>>      
>>>
>>>>3) Map namespaces at a given OMElement:
>>>>
>>>>   void registerNamespace(String uri, String prefix)
>>>>        
>>>>
>>>declareNamespace(.,.)?
>>>
>>>      
>>>
>>>>4) Ensure that we have a consistent view on what is a namespace
>>>>declaration and what is an attribute.  For this XML:
>>>>
>>>>   <foo xmlns:ns1="http://ns1" attr1="bar"/>
>>>>
>>>>EITHER:
>>>>
>>>>getAttributes() returns JUST attr1, and getAllAttributes() returns both
>>>>the ns1 declaration and att1
>>>>
>>>>OR:
>>>>
>>>>getAttributes() returns both attributes.
>>>>
>>>>I prefer the former.  In either case I think we should consistency check
>>>>attributes by noticing if they are namespace declarations when they get
>>>>added.  After this:
>>>>
>>>>   OMAttribute attr = new OMAttribute(new QName(XMLNS, "ns1"),
>>>>                                      "http://ns1");
>>>>   element.addAttribute(attr);
>>>>
>>>>The element should now have a new namespace mapping, and our code should
>>>>complain if the "ns1" prefix is already mapped in this element.
>>>>        
>>>>
>>>So this comes down to whether the AXIOM representation is for XML 1.0
>>>or XML 1.0 + Namespaces. My pref would be to say that its *only* a
>>>namespace aware Infoset model and *never* treat namespace declarations
>>>as attributes.
>>>
>>>That means, getAttribues() only returns "attr1" and we don't have
>>>something called getAllAttributes().
>>>      
>>>
>
>[Chinthaka] I also agree with you for not returning namespaces, when asked
>for allAttributes()
>
>Current OMElement is like this.
>
>We have a getAllAttributes() to return a collection of *only* the
>attributes.
>We have getAllDeclaredNamespaces() in OMElement to retrieve all the
>namespaces declared in this element (not in the scope).
>
>In addition to that we have following methods as Sanjiva and Alek suggested
>earlier.
>
>public OMNamespace declareNamespace(String uri, String prefix);
>    public OMNamespace declareNamespace(OMNamespace namespace);
>
>    public OMNamespace findInScopeNamespace(String uri, String prefix)
>throws OMException;
>
>    public OMNamespace findDeclaredNamespace(String uri, String prefix)
>throws OMException;
>  
>
what is the difference between: findInScopeNamespace and 
findDeclaredNamespace?

if the latter is to get namespace declaration only from current element 
then it is more useful to get list of all declared namespaces in current 
element, something like this:

Iterator<OmNamespace> getDeclaredNamespaces()

alek

-- 
The best way to predict the future is to invent it - Alan Kay


Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Glen Daniels wrote:

> Hi Alek!
>
> Comments below.
>
> Aleksander Slominski wrote:
>
>> Glen Daniels wrote:
>>
>>> Hi Eran, all:
>>>
>>> Eran Chinthaka wrote:
>>>
>>>>>> "Glen Daniels" <gl...@thoughtcraft.com> writes:
>>>>>>
>>>>>>> 3) Map namespaces at a given OMElement:
>>>>>>>
>>>>>>>   void registerNamespace(String uri, String prefix)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> declareNamespace(.,.)?
>>>>>
>>>>>
>>>>>
>>>
>>> Sure.
>>>
>>>>>>> 4) Ensure that we have a consistent view on what is a namespace
>>>>>>> declaration and what is an attribute.  For this XML:
>>>>>>>
>>>>>>>   <foo xmlns:ns1="http://ns1" attr1="bar"/>
>>>>>>>
>>>>>>> EITHER:
>>>>>>>
>>>>>>> getAttributes() returns JUST attr1, and getAllAttributes() 
>>>>>>> returns both
>>>>>>> the ns1 declaration and att1
>>>>>>>
>>>>>>> OR:
>>>>>>>
>>>>>>> getAttributes() returns both attributes.
>>>>>>>
>>>>>>> I prefer the former.  In either case I think we should 
>>>>>>> consistency check
>>>>>>> attributes by noticing if they are namespace declarations when 
>>>>>>> they get
>>>>>>> added.  After this:
>>>>>>>
>>>>>>>   OMAttribute attr = new OMAttribute(new QName(XMLNS, "ns1"),
>>>>>>>                                      "http://ns1");
>>>>>>>   element.addAttribute(attr);
>>>>>>>
>>>>>>> The element should now have a new namespace mapping, and our 
>>>>>>> code should
>>>>>>> complain if the "ns1" prefix is already mapped in this element.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> So this comes down to whether the AXIOM representation is for XML 
>>>>>> 1.0
>>>>>> or XML 1.0 + Namespaces. My pref would be to say that its *only* a
>>>>>> namespace aware Infoset model and *never* treat namespace 
>>>>>> declarations
>>>>>> as attributes.
>>>>>
>>>>>
>>>>>
>>>
>>> I don't think this works, unfortunately - there are some use cases I 
>>> can think of, like encryption/signing, which definitely need the 
>>> ability to get the entire attribute list, in order including 
>>> namespace declarations.  I'm sure there are other scenarios I can't 
>>> think of at the moment, too.
>>>
>>>>>> That means, getAttribues() only returns "attr1" and we don't have
>>>>>> something called getAllAttributes().
>>>>>
>>>>>
>>>>>
>>>
>>> -1, see above.
>>>
>>>> [Chinthaka] I also agree with you for not returning namespaces, 
>>>> when asked
>>>> for allAttributes()
>>>>
>>>> Current OMElement is like this.
>>>>
>>>> We have a getAllAttributes() to return a collection of *only* the
>>>> attributes.
>>>> We have getAllDeclaredNamespaces() in OMElement to retrieve all the
>>>> namespaces declared in this element (not in the scope).
>>>
>>>
>>>
>>>
>>> I'd like to see element.getNamespaces() (or getNamespaceDecls()) to 
>>> get all namespace declarations on this element, and 
>>> element.getInScopeNamespaces() to get all active namespace mappings.
>>>
>>>> In addition to that we have following methods as Sanjiva and Alek 
>>>> suggested
>>>> earlier.
>>>>
>>>> public OMNamespace declareNamespace(String uri, String prefix);
>>>>     public OMNamespace declareNamespace(OMNamespace namespace);
>>>>
>>>>     public OMNamespace findInScopeNamespace(String uri, String prefix)
>>>> throws OMException;
>>>>
>>>>     public OMNamespace findDeclaredNamespace(String uri, String 
>>>> prefix)
>>>> throws OMException;
>>>
>>>
>>>
>>>
>>> Why do we need these last two at all?  Does OMNamespace give me some 
>>> kind of pointer to the OMElement where it is attached?  If not, I 
>>> don't see a reason to have these methods.  If all I want to know is 
>>> whether a particular prefix/uri combination is in scope, I can just do:
>>>
>>> String mappedURI = element.getNamespaceFromPrefix(prefix);
>>
>>
>>
>>> if (myURI.equals(mappedURI)) {
>>>   // namespace is there
>>> }
>>
>>
>>
>> this code looks strange - when do you need to check prefix foo is 
>> bound to some namespace? instead i would resolve prefix to namespace 
>> when recreating QName.
>
>
> I was just noting that I didn't like the findNamespace(String uri, 
> String prefix) operations.  There is definitely a use for finding out 
> what a particular prefix maps to - QName resolution, for instance.  I 
> just think that either you're going to want to find the URI for a 
> prefix, or the prefix for a URI - that's it, no need for OMNamespace 
> objects or methods which take both URI and prefix.
>
>> good point but if you want to use namespace for declarations in other 
>> scope and you want to preserve prefix then OmNamespace is easier to use.
>>
>> URI uri;
>> OmNamespace ns = element.lookupNamespaceForPrefix(prefix);
>> if(ns == null) {
>>    throw new MyException("missing namespace declaration for prefix");
>> }
>>
>> // or one coul ddelcare namespace when building OM
>> OmNamespace ns = element.lookupNamespaceForUri(uri);
>> if(ns == null) {
>>  ns = element.declareNamespace(uri, prefix);
>> }
>
>
> I still don't see what OMNamespace (and it's "OM" not "Om", right? 
> Since OM is an acronym?) buys you.  

it will keep number of objects to represent namespace (it will be 
represented internally as pair <namespaceUri, prefix> anyway) to monimum 
and allows easily to delcare namespaces (as pairs) on child elements and 
attributes (and that includes prefixes!).

> Both of the above pieces of code could have just returned Strings, right?

they could

>
> If I want to know that a given URI is mapped, I do something like:
>
> String prefix = element.getPrefixForNamespace("http://namespace"

you could

> )
>
> If that returns anything other than null, I know it's mapped and I 
> know the prefix.  If it returns "", it's the default namespace.
>
> If I care about a prefix (for resolving a "foo:bar" string, say), I'll 
> do:
>
> String uri = element.getNamespaceForPrefix("foo")
>
> Why is using OMNamespace any better/cleaner?

because you encourage users to keep number of OmNamespace low, code 
simpler, and memory forptint small :)

code i like and use a lot is to delcare namespace as constant and reuse 
it for all messages, ex:

    public final static XmlNamespace POLICY_NS = builder.newNamespace(
        "wsp", "http://schemas.xmlsoap.org/ws/2002/12/policy");

alek

-- 
The best way to predict the future is to invent it - Alan Kay


Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Alek!

Comments below.

Aleksander Slominski wrote:
> Glen Daniels wrote:
> 
>> Hi Eran, all:
>>
>> Eran Chinthaka wrote:
>>
>>>>> "Glen Daniels" <gl...@thoughtcraft.com> writes:
>>>>>
>>>>>> 3) Map namespaces at a given OMElement:
>>>>>>
>>>>>>   void registerNamespace(String uri, String prefix)
>>>>>
>>>>>
>>>>>
>>>>> declareNamespace(.,.)?
>>>>
>>>>
>>
>> Sure.
>>
>>>>>> 4) Ensure that we have a consistent view on what is a namespace
>>>>>> declaration and what is an attribute.  For this XML:
>>>>>>
>>>>>>   <foo xmlns:ns1="http://ns1" attr1="bar"/>
>>>>>>
>>>>>> EITHER:
>>>>>>
>>>>>> getAttributes() returns JUST attr1, and getAllAttributes() returns 
>>>>>> both
>>>>>> the ns1 declaration and att1
>>>>>>
>>>>>> OR:
>>>>>>
>>>>>> getAttributes() returns both attributes.
>>>>>>
>>>>>> I prefer the former.  In either case I think we should consistency 
>>>>>> check
>>>>>> attributes by noticing if they are namespace declarations when 
>>>>>> they get
>>>>>> added.  After this:
>>>>>>
>>>>>>   OMAttribute attr = new OMAttribute(new QName(XMLNS, "ns1"),
>>>>>>                                      "http://ns1");
>>>>>>   element.addAttribute(attr);
>>>>>>
>>>>>> The element should now have a new namespace mapping, and our code 
>>>>>> should
>>>>>> complain if the "ns1" prefix is already mapped in this element.
>>>>>
>>>>>
>>>>>
>>>>> So this comes down to whether the AXIOM representation is for XML 1.0
>>>>> or XML 1.0 + Namespaces. My pref would be to say that its *only* a
>>>>> namespace aware Infoset model and *never* treat namespace declarations
>>>>> as attributes.
>>>>
>>>>
>>
>> I don't think this works, unfortunately - there are some use cases I 
>> can think of, like encryption/signing, which definitely need the 
>> ability to get the entire attribute list, in order including namespace 
>> declarations.  I'm sure there are other scenarios I can't think of at 
>> the moment, too.
>>
>>>>> That means, getAttribues() only returns "attr1" and we don't have
>>>>> something called getAllAttributes().
>>>>
>>>>
>>
>> -1, see above.
>>
>>> [Chinthaka] I also agree with you for not returning namespaces, when 
>>> asked
>>> for allAttributes()
>>>
>>> Current OMElement is like this.
>>>
>>> We have a getAllAttributes() to return a collection of *only* the
>>> attributes.
>>> We have getAllDeclaredNamespaces() in OMElement to retrieve all the
>>> namespaces declared in this element (not in the scope).
>>
>>
>>
>> I'd like to see element.getNamespaces() (or getNamespaceDecls()) to 
>> get all namespace declarations on this element, and 
>> element.getInScopeNamespaces() to get all active namespace mappings.
>>
>>> In addition to that we have following methods as Sanjiva and Alek 
>>> suggested
>>> earlier.
>>>
>>> public OMNamespace declareNamespace(String uri, String prefix);
>>>     public OMNamespace declareNamespace(OMNamespace namespace);
>>>
>>>     public OMNamespace findInScopeNamespace(String uri, String prefix)
>>> throws OMException;
>>>
>>>     public OMNamespace findDeclaredNamespace(String uri, String prefix)
>>> throws OMException;
>>
>>
>>
>> Why do we need these last two at all?  Does OMNamespace give me some 
>> kind of pointer to the OMElement where it is attached?  If not, I 
>> don't see a reason to have these methods.  If all I want to know is 
>> whether a particular prefix/uri combination is in scope, I can just do:
>>
>> String mappedURI = element.getNamespaceFromPrefix(prefix);
> 
> 
>> if (myURI.equals(mappedURI)) {
>>   // namespace is there
>> }
> 
> 
> this code looks strange - when do you need to check prefix foo is bound 
> to some namespace? instead i would resolve prefix to namespace when 
> recreating QName.

I was just noting that I didn't like the findNamespace(String uri, 
String prefix) operations.  There is definitely a use for finding out 
what a particular prefix maps to - QName resolution, for instance.  I 
just think that either you're going to want to find the URI for a 
prefix, or the prefix for a URI - that's it, no need for OMNamespace 
objects or methods which take both URI and prefix.

> good point but if you want to use namespace for declarations in other 
> scope and you want to preserve prefix then OmNamespace is easier to use.
> 
> URI uri;
> OmNamespace ns = element.lookupNamespaceForPrefix(prefix);
> if(ns == null) {
>    throw new MyException("missing namespace declaration for prefix");
> }
> 
> // or one coul ddelcare namespace when building OM
> OmNamespace ns = element.lookupNamespaceForUri(uri);
> if(ns == null) {
>  ns = element.declareNamespace(uri, prefix);
> }

I still don't see what OMNamespace (and it's "OM" not "Om", right? 
Since OM is an acronym?) buys you.  Both of the above pieces of code 
could have just returned Strings, right?

If I want to know that a given URI is mapped, I do something like:

String prefix = element.getPrefixForNamespace("http://namespace")

If that returns anything other than null, I know it's mapped and I know 
the prefix.  If it returns "", it's the default namespace.

If I care about a prefix (for resolving a "foo:bar" string, say), I'll do:

String uri = element.getNamespaceForPrefix("foo")

Why is using OMNamespace any better/cleaner?

--Glen

Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Glen Daniels wrote:

> Hi Eran, all:
>
> Eran Chinthaka wrote:
>
>>>> "Glen Daniels" <gl...@thoughtcraft.com> writes:
>>>>
>>>>> 3) Map namespaces at a given OMElement:
>>>>>
>>>>>   void registerNamespace(String uri, String prefix)
>>>>
>>>>
>>>> declareNamespace(.,.)?
>>>
>
> Sure.
>
>>>>> 4) Ensure that we have a consistent view on what is a namespace
>>>>> declaration and what is an attribute.  For this XML:
>>>>>
>>>>>   <foo xmlns:ns1="http://ns1" attr1="bar"/>
>>>>>
>>>>> EITHER:
>>>>>
>>>>> getAttributes() returns JUST attr1, and getAllAttributes() returns 
>>>>> both
>>>>> the ns1 declaration and att1
>>>>>
>>>>> OR:
>>>>>
>>>>> getAttributes() returns both attributes.
>>>>>
>>>>> I prefer the former.  In either case I think we should consistency 
>>>>> check
>>>>> attributes by noticing if they are namespace declarations when 
>>>>> they get
>>>>> added.  After this:
>>>>>
>>>>>   OMAttribute attr = new OMAttribute(new QName(XMLNS, "ns1"),
>>>>>                                      "http://ns1");
>>>>>   element.addAttribute(attr);
>>>>>
>>>>> The element should now have a new namespace mapping, and our code 
>>>>> should
>>>>> complain if the "ns1" prefix is already mapped in this element.
>>>>
>>>>
>>>> So this comes down to whether the AXIOM representation is for XML 1.0
>>>> or XML 1.0 + Namespaces. My pref would be to say that its *only* a
>>>> namespace aware Infoset model and *never* treat namespace declarations
>>>> as attributes.
>>>
>
> I don't think this works, unfortunately - there are some use cases I 
> can think of, like encryption/signing, which definitely need the 
> ability to get the entire attribute list, in order including namespace 
> declarations.  I'm sure there are other scenarios I can't think of at 
> the moment, too.
>
>>>> That means, getAttribues() only returns "attr1" and we don't have
>>>> something called getAllAttributes().
>>>
>
> -1, see above.
>
>> [Chinthaka] I also agree with you for not returning namespaces, when 
>> asked
>> for allAttributes()
>>
>> Current OMElement is like this.
>>
>> We have a getAllAttributes() to return a collection of *only* the
>> attributes.
>> We have getAllDeclaredNamespaces() in OMElement to retrieve all the
>> namespaces declared in this element (not in the scope).
>
>
> I'd like to see element.getNamespaces() (or getNamespaceDecls()) to 
> get all namespace declarations on this element, and 
> element.getInScopeNamespaces() to get all active namespace mappings.
>
>> In addition to that we have following methods as Sanjiva and Alek 
>> suggested
>> earlier.
>>
>> public OMNamespace declareNamespace(String uri, String prefix);
>>     public OMNamespace declareNamespace(OMNamespace namespace);
>>
>>     public OMNamespace findInScopeNamespace(String uri, String prefix)
>> throws OMException;
>>
>>     public OMNamespace findDeclaredNamespace(String uri, String prefix)
>> throws OMException;
>
>
> Why do we need these last two at all?  Does OMNamespace give me some 
> kind of pointer to the OMElement where it is attached?  If not, I 
> don't see a reason to have these methods.  If all I want to know is 
> whether a particular prefix/uri combination is in scope, I can just do:
>
> String mappedURI = element.getNamespaceFromPrefix(prefix);

> if (myURI.equals(mappedURI)) {
>   // namespace is there
> }

this code looks strange - when do you need to check prefix foo is bound 
to some namespace? instead i would resolve prefix to namespace when 
recreating QName.

good point but if you want to use namespace for declarations in other 
scope and you want to preserve prefix then OmNamespace is easier to use.

URI uri;
OmNamespace ns = element.lookupNamespaceForPrefix(prefix);
if(ns == null) {
    throw new MyException("missing namespace declaration for prefix");
}

// or one coul ddelcare namespace when building OM
OmNamespace ns = element.lookupNamespaceForUri(uri);
if(ns == null) {
  ns = element.declareNamespace(uri, prefix);
}


alek

-- 
The best way to predict the future is to invent it - Alan Kay


Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Eran, all:

Eran Chinthaka wrote:
>>>"Glen Daniels" <gl...@thoughtcraft.com> writes:
>>>
>>>>3) Map namespaces at a given OMElement:
>>>>
>>>>   void registerNamespace(String uri, String prefix)
>>>
>>>declareNamespace(.,.)?

Sure.

>>>>4) Ensure that we have a consistent view on what is a namespace
>>>>declaration and what is an attribute.  For this XML:
>>>>
>>>>   <foo xmlns:ns1="http://ns1" attr1="bar"/>
>>>>
>>>>EITHER:
>>>>
>>>>getAttributes() returns JUST attr1, and getAllAttributes() returns both
>>>>the ns1 declaration and att1
>>>>
>>>>OR:
>>>>
>>>>getAttributes() returns both attributes.
>>>>
>>>>I prefer the former.  In either case I think we should consistency check
>>>>attributes by noticing if they are namespace declarations when they get
>>>>added.  After this:
>>>>
>>>>   OMAttribute attr = new OMAttribute(new QName(XMLNS, "ns1"),
>>>>                                      "http://ns1");
>>>>   element.addAttribute(attr);
>>>>
>>>>The element should now have a new namespace mapping, and our code should
>>>>complain if the "ns1" prefix is already mapped in this element.
>>>
>>>So this comes down to whether the AXIOM representation is for XML 1.0
>>>or XML 1.0 + Namespaces. My pref would be to say that its *only* a
>>>namespace aware Infoset model and *never* treat namespace declarations
>>>as attributes.

I don't think this works, unfortunately - there are some use cases I can 
think of, like encryption/signing, which definitely need the ability to 
get the entire attribute list, in order including namespace 
declarations.  I'm sure there are other scenarios I can't think of at 
the moment, too.

>>>That means, getAttribues() only returns "attr1" and we don't have
>>>something called getAllAttributes().

-1, see above.

> [Chinthaka] I also agree with you for not returning namespaces, when asked
> for allAttributes()
> 
> Current OMElement is like this.
> 
> We have a getAllAttributes() to return a collection of *only* the
> attributes.
> We have getAllDeclaredNamespaces() in OMElement to retrieve all the
> namespaces declared in this element (not in the scope).

I'd like to see element.getNamespaces() (or getNamespaceDecls()) to get 
all namespace declarations on this element, and 
element.getInScopeNamespaces() to get all active namespace mappings.

> In addition to that we have following methods as Sanjiva and Alek suggested
> earlier.
> 
> public OMNamespace declareNamespace(String uri, String prefix);
>     public OMNamespace declareNamespace(OMNamespace namespace);
> 
>     public OMNamespace findInScopeNamespace(String uri, String prefix)
> throws OMException;
> 
>     public OMNamespace findDeclaredNamespace(String uri, String prefix)
> throws OMException;

Why do we need these last two at all?  Does OMNamespace give me some 
kind of pointer to the OMElement where it is attached?  If not, I don't 
see a reason to have these methods.  If all I want to know is whether a 
particular prefix/uri combination is in scope, I can just do:

String mappedURI = element.getNamespaceFromPrefix(prefix);
if (myURI.equals(mappedURI)) {
   // namespace is there
}

Thanks,
--Glen

RE: [Axis2][OM] Simpler way to get NameSpace

Posted by Eran Chinthaka <ch...@opensource.lk>.
>>
>>"Glen Daniels" <gl...@thoughtcraft.com> writes:
>>> 3) Map namespaces at a given OMElement:
>>>
>>>    void registerNamespace(String uri, String prefix)
>>
>>declareNamespace(.,.)?
>>
>>> 4) Ensure that we have a consistent view on what is a namespace
>>> declaration and what is an attribute.  For this XML:
>>>
>>>    <foo xmlns:ns1="http://ns1" attr1="bar"/>
>>>
>>> EITHER:
>>>
>>> getAttributes() returns JUST attr1, and getAllAttributes() returns both
>>> the ns1 declaration and att1
>>>
>>> OR:
>>>
>>> getAttributes() returns both attributes.
>>>
>>> I prefer the former.  In either case I think we should consistency check
>>> attributes by noticing if they are namespace declarations when they get
>>> added.  After this:
>>>
>>>    OMAttribute attr = new OMAttribute(new QName(XMLNS, "ns1"),
>>>                                       "http://ns1");
>>>    element.addAttribute(attr);
>>>
>>> The element should now have a new namespace mapping, and our code should
>>> complain if the "ns1" prefix is already mapped in this element.
>>
>>So this comes down to whether the AXIOM representation is for XML 1.0
>>or XML 1.0 + Namespaces. My pref would be to say that its *only* a
>>namespace aware Infoset model and *never* treat namespace declarations
>>as attributes.
>>
>>That means, getAttribues() only returns "attr1" and we don't have
>>something called getAllAttributes().

[Chinthaka] I also agree with you for not returning namespaces, when asked
for allAttributes()

Current OMElement is like this.

We have a getAllAttributes() to return a collection of *only* the
attributes.
We have getAllDeclaredNamespaces() in OMElement to retrieve all the
namespaces declared in this element (not in the scope).

In addition to that we have following methods as Sanjiva and Alek suggested
earlier.

public OMNamespace declareNamespace(String uri, String prefix);
    public OMNamespace declareNamespace(OMNamespace namespace);

    public OMNamespace findInScopeNamespace(String uri, String prefix)
throws OMException;

    public OMNamespace findDeclaredNamespace(String uri, String prefix)
throws OMException;


Thankx and regards
-- Eran Chinthaka

>>
>>Sanjiva.
>>




Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
"Glen Daniels" <gl...@thoughtcraft.com> writes:
> 3) Map namespaces at a given OMElement:
> 
>    void registerNamespace(String uri, String prefix)

declareNamespace(.,.)?

> 4) Ensure that we have a consistent view on what is a namespace 
> declaration and what is an attribute.  For this XML:
> 
>    <foo xmlns:ns1="http://ns1" attr1="bar"/>
> 
> EITHER:
> 
> getAttributes() returns JUST attr1, and getAllAttributes() returns both 
> the ns1 declaration and att1
> 
> OR:
> 
> getAttributes() returns both attributes.
> 
> I prefer the former.  In either case I think we should consistency check 
> attributes by noticing if they are namespace declarations when they get 
> added.  After this:
> 
>    OMAttribute attr = new OMAttribute(new QName(XMLNS, "ns1"),
>                                       "http://ns1");
>    element.addAttribute(attr);
> 
> The element should now have a new namespace mapping, and our code should 
> complain if the "ns1" prefix is already mapped in this element.

So this comes down to whether the AXIOM representation is for XML 1.0
or XML 1.0 + Namespaces. My pref would be to say that its *only* a
namespace aware Infoset model and *never* treat namespace declarations
as attributes.

That means, getAttribues() only returns "attr1" and we don't have
something called getAllAttributes().

Sanjiva.


Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Glen Daniels <gl...@thoughtcraft.com>.
Wow, lots of namespace mail indeed!

Here's my take on the matter.  First, I really like the way Axis 1.1 
deals with a lot of this stuff, and I would recommend that folks check 
out that code when continuing forward.  The Axis 1.1 util.Mapping object 
is pretty equivalent to OMNamespace, and it doesn't get very exposed to 
users - they can use it, but they aren't forced to.

As a user of OM, I want the ability to:

1) Resolve namespaces from a given OMElement:

   String getPrefixForNamespace(String uri)
   String getNamespaceForPrefix(String prefix)

2) Translate QNames to and from string representations in a given 
context (OMElement):

   QName getQNameFromString(String prefixedName)

This turns names like "foo:bar" into QName{"http://foo", "bar"}, or 
throws a well-defined exception if the prefix isn't mapped.  If there's 
no prefix on the prefixedName, we need to be able to control whether the 
default namespace gets used or not.

   String getPrefixedName(QName qname,
                          boolean autoAdd,
                          boolean useDefault)

The reverse.  If the namespace of the qname is not in scope, and the 
"autoAdd" argument is true, then getPrefixedName() should add a 
namespace declaration to the current OMElement with a random unused 
prefix (we could also have a form with a preferred prefix).  If 
useDefault is true, then we'll use a non-prefixed name if the namespace 
matches the default namespace.

3) Map namespaces at a given OMElement:

   void registerNamespace(String uri, String prefix)

4) Ensure that we have a consistent view on what is a namespace 
declaration and what is an attribute.  For this XML:

   <foo xmlns:ns1="http://ns1" attr1="bar"/>

EITHER:

getAttributes() returns JUST attr1, and getAllAttributes() returns both 
the ns1 declaration and att1

OR:

getAttributes() returns both attributes.

I prefer the former.  In either case I think we should consistency check 
attributes by noticing if they are namespace declarations when they get 
added.  After this:

   OMAttribute attr = new OMAttribute(new QName(XMLNS, "ns1"),
                                      "http://ns1");
   element.addAttribute(attr);

The element should now have a new namespace mapping, and our code should 
complain if the "ns1" prefix is already mapped in this element.

--Glen

Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Eran Chinthaka wrote:

>  
>
>>>Srinath Perera wrote:
>>>
>>>      
>>>
>>>>>So, let me try to summarize where we are now w.r.t. namespaces:
>>>>>
>>>>>   interface OmNamespace {
>>>>>       public String getName (); // seems redundant to say
>>>>>getNamespaceName!
>>>>>       public String getPrefix ();
>>>>>   }
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>+1
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>OMElement has the following:
>>>>>
>>>>>   interface OmElement extends OmNode {
>>>>>
>>>>>
>>>>>          
>>>>>
>>>why does this have to extend OmNode?
>>>
>>>      
>>>
>>>>>       // declare a namespace at this element
>>>>>       public OmNamespace declareNamespace (String uri, String prefix);
>>>>>
>>>>>
>>>>>          
>>>>>
>>>also declareNamespace(OmNamespace) to allow reuse of namespace
>>>declarations (perfectly fine and safe if OmNamespace is immutable)
>>>
>>>      
>>>
>>>>>       // find a namespace declaration here or from parent
>>>>>       public OmNamespace findNamespace (String uri, String prefix);
>>>>>
>>>>>
>>>>>          
>>>>>
>>>i guess:
>>>
>>>if prefix != null && uri != null find OmNamespace that has
>>>OmNamespace.getPrefix() == prefix && OmNamespace.getName() == uri
>>>if uri != null find OmNamespace that has OmNamespace.getName() == uri
>>>if prefix != null find OmNamespace that has OmNamespace.getPrefix() ==
>>>prefix
>>>
>>>what happens for findNamespace(null, null) ?!
>>>      
>>>
>
>[Chinthaka] I think having two methods is bit of a over doing. 
>We can do the samething using one method.
>If u try to address the findNamespace(null, null) problem using two methods,
>u r in trouble again, as what if findNamespaceByPrefix(null) or
>findNamespaceByUri (null).
>  
>
it is obvious that it is wrong - throw IllegalArgumentException (IAE)

the same for setLocalName(String localName) what if setLocalName(null)? IAE

>I think its better to have one method like 
>	OmNamespace findNamespace (String uri, String prefix);
>If findNamespace(null,null), just throw an exception or return all. 
>
will be harder to read code

findNamespace(null, prefix) 

than

findNamespaceByPrefix( prefix )


>But if
>we want to return all there should be another method like
>Collection findNamespace (String uri, String prefix);
>  
>
i would say it is too complicated (and i never needed it - if really 
needed user can walk XML tree and retrieve declared namespaces to get 
list of all) - i would just return first namespace that has given prefix 
or uri


>And there is one other problem.
>What if someone try to retrieve all the namespace which has some prefix.
>  
>
return first one

>Say findNamespace(null,prefix). SO this should return a collection. Or else,
>we document and say if there is more than one we just return the first one.
>  
>
what are use cases?

thanks,

alek

-- 
The best way to predict the future is to invent it - Alan Kay


RE: [Axis2][OM] Simpler way to get NameSpace

Posted by Eran Chinthaka <ch...@opensource.lk>.

>>
>>Srinath Perera wrote:
>>
>>>>So, let me try to summarize where we are now w.r.t. namespaces:
>>>>
>>>>    interface OmNamespace {
>>>>        public String getName (); // seems redundant to say
>>>>getNamespaceName!
>>>>        public String getPrefix ();
>>>>    }
>>>>
>>>>
>>>+1
>>>
>>>
>>>
>>>>OMElement has the following:
>>>>
>>>>    interface OmElement extends OmNode {
>>>>
>>>>
>>why does this have to extend OmNode?
>>
>>>>        // declare a namespace at this element
>>>>        public OmNamespace declareNamespace (String uri, String prefix);
>>>>
>>>>
>>also declareNamespace(OmNamespace) to allow reuse of namespace
>>declarations (perfectly fine and safe if OmNamespace is immutable)
>>
>>>>        // find a namespace declaration here or from parent
>>>>        public OmNamespace findNamespace (String uri, String prefix);
>>>>
>>>>
>>i guess:
>>
>>if prefix != null && uri != null find OmNamespace that has
>>OmNamespace.getPrefix() == prefix && OmNamespace.getName() == uri
>>if uri != null find OmNamespace that has OmNamespace.getName() == uri
>>if prefix != null find OmNamespace that has OmNamespace.getPrefix() ==
>>prefix
>>
>>what happens for findNamespace(null, null) ?!

[Chinthaka] I think having two methods is bit of a over doing. 
We can do the samething using one method.
If u try to address the findNamespace(null, null) problem using two methods,
u r in trouble again, as what if findNamespaceByPrefix(null) or
findNamespaceByUri (null).

I think its better to have one method like 
	OmNamespace findNamespace (String uri, String prefix);
If findNamespace(null,null), just throw an exception or return all. But if
we want to return all there should be another method like
Collection findNamespace (String uri, String prefix);

And there is one other problem.
What if someone try to retrieve all the namespace which has some prefix.

Say findNamespace(null,prefix). SO this should return a collection. Or else,
we document and say if there is more than one we just return the first one.

Comments ???

Regards
-- Eran Chinthaka

>>
>>maybe better is to have two functions?
>>
>>        public OmNamespace findNamespaceByPrefix (String prefix);
>>        public OmNamespace findNamespaceByUri (String uri);
>>
>>
>>>>        // get my namespace name
>>>>        public String getNamespaceName ();
>>>>
>>>>        // get my local name
>>>>        public String getLocalName ();
>>>>
>>>>        ..
>>>>    }
>>>>
>>>>
>>>+1 Think  we are converging :) are we ?
>>>
>>>
>>looks good to me?
>>
>>--
>>The best way to predict the future is to invent it - Alan Kay
>>




Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Srinath Perera wrote:

>>So, let me try to summarize where we are now w.r.t. namespaces:
>>
>>    interface OmNamespace {
>>        public String getName (); // seems redundant to say
>>getNamespaceName!
>>        public String getPrefix ();
>>    }
>>    
>>
>+1 
> 
>  
>
>>OMElement has the following:
>>
>>    interface OmElement extends OmNode {
>>    
>>
why does this have to extend OmNode?

>>        // declare a namespace at this element
>>        public OmNamespace declareNamespace (String uri, String prefix);
>>    
>>
also declareNamespace(OmNamespace) to allow reuse of namespace 
declarations (perfectly fine and safe if OmNamespace is immutable)

>>        // find a namespace declaration here or from parent
>>        public OmNamespace findNamespace (String uri, String prefix);
>>    
>>
i guess:

if prefix != null && uri != null find OmNamespace that has 
OmNamespace.getPrefix() == prefix && OmNamespace.getName() == uri
if uri != null find OmNamespace that has OmNamespace.getName() == uri
if prefix != null find OmNamespace that has OmNamespace.getPrefix() == 
prefix

what happens for findNamespace(null, null) ?!

maybe better is to have two functions?

        public OmNamespace findNamespaceByPrefix (String prefix);
        public OmNamespace findNamespaceByUri (String uri);


>>        // get my namespace name
>>        public String getNamespaceName ();
>>
>>        // get my local name
>>        public String getLocalName ();
>>
>>        ..
>>    }
>>    
>>
>+1 Think  we are converging :) are we ?
>  
>
looks good to me?

-- 
The best way to predict the future is to invent it - Alan Kay


Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Srinath Perera <he...@gmail.com>.
> So, let me try to summarize where we are now w.r.t. namespaces:
> 
>     interface OmNamespace {
>         public String getName (); // seems redundant to say
> getNamespaceName!
>         public String getPrefix ();
>     }
+1 
 
> OMElement has the following:
> 
>     interface OmElement extends OmNode {
>         // declare a namespace at this element
>         public OmNamespace declareNamespace (String uri, String prefix);
> 
>         // find a namespace declaration here or from parent
>         public OmNamespace findNamespace (String uri, String prefix);
> 
>         // get my namespace name
>         public String getNamespaceName ();
> 
>         // get my local name
>         public String getLocalName ();
> 
>         ..
>     }
+1 Think  we are converging :) are we ?
Thanks
Srinath

Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Sanjiva Weerawarana wrote:

>"Eran Chinthaka" <ch...@opensource.lk> writes:
>  
>
>>[Chinthaka] I think there should be a method to retrieve all the namespace
>>declarations in an element as well.
>>So how abt
>>+ getAllNamespaceDeclarations)(): Iterator
>>
>>
>>This iterator will have OMNamespace objects.
>>    
>>
>
>+1. But a question:
>
>Do you return *only* those namespaces that are explicitly declared
>on that element or all in-scope namespaces? If its the latter
>(which is presumably what's more useful) then I suggest naming
>the method:
>    getInScopeNamespaceDeclarations ()
>And if you also want to return all namespaces that are declared
>on the current element only then:
>    getDeclaredNamespaceDeclarations ()
>
>This is somewhat consistent with java.lang.Class.getMethods and
>getDeclaredMethods.
>  
>
i think it is good idea and makes API easier to read.

alek

-- 
The best way to predict the future is to invent it - Alan Kay


RE: [Axis2][OM] Simpler way to get NameSpace

Posted by Eran Chinthaka <ch...@opensource.lk>.

>>
>>"Eran Chinthaka" <ch...@opensource.lk> writes:
>>>
>>> [Chinthaka] I think there should be a method to retrieve all the
>>namespace
>>> declarations in an element as well.
>>> So how abt
>>> + getAllNamespaceDeclarations)(): Iterator
>>>
>>>
>>> This iterator will have OMNamespace objects.
>>
>>+1. But a question:
>>
>>Do you return *only* those namespaces that are explicitly declared
>>on that element or all in-scope namespaces? If its the latter
>>(which is presumably what's more useful) then I suggest naming
>>the method:
>>    getInScopeNamespaceDeclarations ()
>>And if you also want to return all namespaces that are declared
>>on the current element only then:
>>    getDeclaredNamespaceDeclarations ()
>>
>>This is somewhat consistent with java.lang.Class.getMethods and
>>getDeclaredMethods.

[Chinthaka] +1 to have two methods. 
One might think that we have some additional methods, but can't help. We
have to cater and be flexible to everyone as far as possible.

Regards,
Eran Chinthaka

>>
>>Sanjiva.
>>




Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
"Eran Chinthaka" <ch...@opensource.lk> writes:
>
> [Chinthaka] I think there should be a method to retrieve all the namespace
> declarations in an element as well.
> So how abt
> + getAllNamespaceDeclarations)(): Iterator
>
>
> This iterator will have OMNamespace objects.

+1. But a question:

Do you return *only* those namespaces that are explicitly declared
on that element or all in-scope namespaces? If its the latter
(which is presumably what's more useful) then I suggest naming
the method:
    getInScopeNamespaceDeclarations ()
And if you also want to return all namespaces that are declared
on the current element only then:
    getDeclaredNamespaceDeclarations ()

This is somewhat consistent with java.lang.Class.getMethods and
getDeclaredMethods.

Sanjiva.


RE: [Axis2][OM] Simpler way to get NameSpace

Posted by Eran Chinthaka <ch...@opensource.lk>.


>>
>>> >To start with I don't that much understand why Srinath wanna remove
>>> >OMNamespace from the API and "Hide" it. Has it committed a crime ?? :)
>>> >
>>> >
>>> bad bad namespaces let remove them and if not at least let hide them ;-)
>>
>>Now now .. in both Sri Lanka and the US its no longer necessary
>>to commit a crime to shove someone in jail and keep 'em away
>>for a long time! So why should we be better? ;-)
>>
>>> unfortunately if you hide OmNamespace you loose opportunities to make OM
>>> more lightweight and faster - for example you can optimize OM impl so it
>>> avoid creation of duplicate OmNamespace(prefix, uri) so then you have
>>> essentially interned it and as for String.intern() you can use fast ==
>>> instead of equals() besides it makes API easier if you have OmNamespace
>>> when you do operations on *namespaces*...
>>
>>OK that's a good reason to keep the interface. Efficiency is good.
>>We MUST document then that any implementation must use intern to make
>>"==" work correctly.
>>
>>> >First I will explain the rationale behind some namespace methods in
>>> >OMElement.
>>> >
>>> > The resolveNamespace(uri, prefix) is there to check whether there
>>> >are any namespaces already created with the given info.
>>> >The reason behind having this is that, one can avoid having two
>>namespaces
>>> >with same uri and prefix.
>>
>>OK - so resolveNamespace will return an OmNamespace, right? I suggest
>>we change the name to "findNamespace" then as its not really
>>"resolving" it but rather finding a namespace declaration:
>>
>>    interface OmElement {
>>        public OmNamespace findNamespace (String uri, String prefix);
>>    }
>>
>>However, I agree with Srinath that having this does not change the
>>need to have simple getNamespaceName() and getPrefix() methods on
>>named nodes.
>>
>>> >I think as Sanjiva suggested
>>> >resolveNamespace(prefix) should also be there.
>>
>>+1.
>>
>>> >Yes but that finds
>>> >But according to what Alek said, I agree that this should be
>>> >resolveNamespace(uri). But this means, there can be two (or more)
>>namespace
>>> >with different prefixes, but same URI ? Do we wanna allow that ??
>>> >
>>> >
>>> that is legal in XML 1.0 with namespaces? so API should allow it ...
>>
>>+1.
>>
>>> > The createNamespace(uri, prefix) - I agree to rename this as
>>> >declareNamespace :)
>>
>>+1 .. and shall we have it return the resulting OmNamespace node:
>>
>>    public OmNamespace declareNamespace (String uri, String prefix)
>>
>>That saves one from having to look it up again to find the OmNamespace.
>>
>>> i disagree with this assumption - if most of access is through iterators
>>> then next/prevSibling is not needed.
>>
>>+1 for making OmNamespace *not* extend OmNode.
>>
>>So, let me try to summarize where we are now w.r.t. namespaces:
>>
>>    interface OmNamespace {
>>        public String getName (); // seems redundant to say
>>getNamespaceName!
>>        public String getPrefix ();
>>    }
>>
>>OMElement has the following:
>>
>>    interface OmElement extends OmNode {
>>        // declare a namespace at this element
>>        public OmNamespace declareNamespace (String uri, String prefix);
>>
>>        // find a namespace declaration here or from parent
>>        public OmNamespace findNamespace (String uri, String prefix);
>>
>>        // get my namespace name
>>        public String getNamespaceName ();
>>
>>        // get my local name
>>        public String getLocalName ();
>>
>>        ..
>>    }
>>
>>(I guess these will go into NamedNode .. sorry for being sloppy.)
>>
>>Comments?

[Chinthaka] I think there should be a method to retrieve all the namespace
declarations in an element as well.
So how abt
+ getAllNamespaceDeclarations)(): Iterator


This iterator will have OMNamespace objects.

Comments .. ??

Eran Chinthaka



>>
>>Sanjiva.
>>




Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
> >To start with I don't that much understand why Srinath wanna remove
> >OMNamespace from the API and "Hide" it. Has it committed a crime ?? :)
> >
> >
> bad bad namespaces let remove them and if not at least let hide them ;-)

Now now .. in both Sri Lanka and the US its no longer necessary
to commit a crime to shove someone in jail and keep 'em away
for a long time! So why should we be better? ;-)

> unfortunately if you hide OmNamespace you loose opportunities to make OM
> more lightweight and faster - for example you can optimize OM impl so it
> avoid creation of duplicate OmNamespace(prefix, uri) so then you have
> essentially interned it and as for String.intern() you can use fast ==
> instead of equals() besides it makes API easier if you have OmNamespace
> when you do operations on *namespaces*...

OK that's a good reason to keep the interface. Efficiency is good.
We MUST document then that any implementation must use intern to make
"==" work correctly.

> >First I will explain the rationale behind some namespace methods in
> >OMElement.
> >
> > The resolveNamespace(uri, prefix) is there to check whether there
> >are any namespaces already created with the given info.
> >The reason behind having this is that, one can avoid having two
namespaces
> >with same uri and prefix.

OK - so resolveNamespace will return an OmNamespace, right? I suggest
we change the name to "findNamespace" then as its not really
"resolving" it but rather finding a namespace declaration:

    interface OmElement {
        public OmNamespace findNamespace (String uri, String prefix);
    }

However, I agree with Srinath that having this does not change the
need to have simple getNamespaceName() and getPrefix() methods on
named nodes.

> >I think as Sanjiva suggested
> >resolveNamespace(prefix) should also be there.

+1.

> >Yes but that finds
> >But according to what Alek said, I agree that this should be
> >resolveNamespace(uri). But this means, there can be two (or more)
namespace
> >with different prefixes, but same URI ? Do we wanna allow that ??
> >
> >
> that is legal in XML 1.0 with namespaces? so API should allow it ...

+1.

> > The createNamespace(uri, prefix) - I agree to rename this as
> >declareNamespace :)

+1 .. and shall we have it return the resulting OmNamespace node:

    public OmNamespace declareNamespace (String uri, String prefix)

That saves one from having to look it up again to find the OmNamespace.

> i disagree with this assumption - if most of access is through iterators
> then next/prevSibling is not needed.

+1 for making OmNamespace *not* extend OmNode.

So, let me try to summarize where we are now w.r.t. namespaces:

    interface OmNamespace {
        public String getName (); // seems redundant to say
getNamespaceName!
        public String getPrefix ();
    }

OMElement has the following:

    interface OmElement extends OmNode {
        // declare a namespace at this element
        public OmNamespace declareNamespace (String uri, String prefix);

        // find a namespace declaration here or from parent
        public OmNamespace findNamespace (String uri, String prefix);

        // get my namespace name
        public String getNamespaceName ();

        // get my local name
        public String getLocalName ();

        ..
    }

(I guess these will go into NamedNode .. sorry for being sloppy.)

Comments?

Sanjiva.


Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Eran Chinthaka wrote:

>  
>
>>>Eran Chinthaka wrote:
>>>
>>>      
>>>
>>>>Oh, I think I missed a lot, just being absent for one day.
>>>>
>>>>BTW : Let me answer the questions, even though I'm bit late. I might have
>>>>missed some mails, if yes, please forgive me.
>>>>
>>>>To start with I don't that much understand why Srinath wanna remove
>>>>OMNamespace from the API and "Hide" it. Has it committed a crime ?? :)
>>>>
>>>>
>>>>        
>>>>
>>>bad bad namespaces let remove them and if not at least let hide them ;-)
>>>
>>>unfortunately if you hide OmNamespace you loose opportunities to make OM
>>>more lightweight and faster - for example you can optimize OM impl so it
>>>avoid creation of duplicate OmNamespace(prefix, uri) so then you have
>>>essentially interned it and as for String.intern() you can use fast ==
>>>instead of equals() besides it makes API easier if you have OmNamespace
>>>when you do operations on *namespaces*...
>>>      
>>>
>
>[Chinthaka] Alek, u seems compromise ? I still like to keep OMNamespace.
>  
>
i am for keeping them - they are in XML Infoset and have natural 
identity especially when representing nested elements and attributes 
"sharing the same namespace" ...

>  
>
>>>>First I will explain the rationale behind some namespace methods in
>>>>OMElement.
>>>>
>>>>	The resolveNamespace(uri, prefix) is there to check whether there
>>>>are any namespaces already created with the given info.
>>>>The reason behind having this is that, one can avoid having two
>>>>        
>>>>
>>>namespaces
>>>      
>>>
>>>>with same uri and prefix. I think as Sanjiva suggested
>>>>resolveNamespace(prefix) should also be there.
>>>>But according to what Alek said, I agree that this should be
>>>>resolveNamespace(uri). But this means, there can be two (or more)
>>>>        
>>>>
>>>namespace
>>>      
>>>
>>>>with different prefixes, but same URI ? Do we wanna allow that ??
>>>>
>>>>
>>>>        
>>>>
>>>that is legal in XML 1.0 with namespaces? so API should allow it ...
>>>      
>>>
>
>[Chinthaka] so we agree to allow, two namespaces, with different prefixes,
>but same URI ?
>  
>
there are many documents with such declarations and nothing in spec 
prevents it:
http://www.w3.org/TR/REC-xml-names/#scoping

>  
>
>>>>	The createNamespace(uri, prefix) - I agree to rename this as
>>>>declareNamespace :)
>>>>
>>>>And I agree that OMNamespace must have following methods.
>>>>	- String getNamespaceName ()
>>>>   	- String getNamespacePrefix ()
>>>>
>>>>The rationale behind OMNamespace extends OMNode is that, we store
>>>>        
>>>>
>>>Namespaces
>>>      
>>>
>>>>in the element as a linked list. I agree that this extending from some
>>>>        
>>>>
>>>what
>>>      
>>>
>>>>weird OMNode. I think the name is not correct. We want to have
>>>>getNextSibling, insertSibling etc., to OMNamespace as well.
>>>>One must agree that OMNamespace *MUST* have getNextSibling, insertSibling
>>>>etc.,
>>>>
>>>>
>>>>        
>>>>
>>>i disagree with this assumption - if most of access is through iterators
>>>then next/prevSibling is not needed.
>>>      
>>>
>
>[Chinthaka] I think I have to reconsider this. 
>How about the parent element having a vector sort of something to hold
>namespace declarations, rather than having a linked list of OMNamespace.
>So we have an enumerated class called OMNamespace, which has only uri and
>prefix as attributes and getters and setters for that.
>  
>
i would avoid setters - keeping objects as immutable value objects is 
more efficient and good pattern:
http://c2.com/cgi/wiki?ImmutableValue

>
>I have another small problem, if someone need to get all the namespace
>declarations an Element has, how can we provide it ? This will be used by
>the Serialiser, as we thought of keeping serialisers out of OM. (if this is
>also debatable, just defer that and assume as it).
>  
>

>Then how serialiser will get all the namespaces is that 
>	Iterator namespaceIter = element.getNamespaceDeclarations();
>	While(namespaceIter.hasNext()){
>		OMNamespace namespace = (OMNamespace) namespaceIter.next();
>		
>	}
>
>So, is this OK ? and this required we need an interface for Namespaces,
>which we can "hide".
>  
>
looks good to me.

alek

-- 
The best way to predict the future is to invent it - Alan Kay


RE: [Axis2][OM] Simpler way to get NameSpace

Posted by Eran Chinthaka <ch...@opensource.lk>.

>>
>>Eran Chinthaka wrote:
>>
>>>Oh, I think I missed a lot, just being absent for one day.
>>>
>>>BTW : Let me answer the questions, even though I'm bit late. I might have
>>>missed some mails, if yes, please forgive me.
>>>
>>>To start with I don't that much understand why Srinath wanna remove
>>>OMNamespace from the API and "Hide" it. Has it committed a crime ?? :)
>>>
>>>
>>bad bad namespaces let remove them and if not at least let hide them ;-)
>>
>>unfortunately if you hide OmNamespace you loose opportunities to make OM
>>more lightweight and faster - for example you can optimize OM impl so it
>>avoid creation of duplicate OmNamespace(prefix, uri) so then you have
>>essentially interned it and as for String.intern() you can use fast ==
>>instead of equals() besides it makes API easier if you have OmNamespace
>>when you do operations on *namespaces*...

[Chinthaka] Alek, u seems compromise ? I still like to keep OMNamespace.

>>
>>>First I will explain the rationale behind some namespace methods in
>>>OMElement.
>>>
>>>	The resolveNamespace(uri, prefix) is there to check whether there
>>>are any namespaces already created with the given info.
>>>The reason behind having this is that, one can avoid having two
>>namespaces
>>>with same uri and prefix. I think as Sanjiva suggested
>>>resolveNamespace(prefix) should also be there.
>>>But according to what Alek said, I agree that this should be
>>>resolveNamespace(uri). But this means, there can be two (or more)
>>namespace
>>>with different prefixes, but same URI ? Do we wanna allow that ??
>>>
>>>
>>that is legal in XML 1.0 with namespaces? so API should allow it ...

[Chinthaka] so we agree to allow, two namespaces, with different prefixes,
but same URI ?

>>
>>>	The createNamespace(uri, prefix) - I agree to rename this as
>>>declareNamespace :)
>>>
>>>And I agree that OMNamespace must have following methods.
>>>	- String getNamespaceName ()
>>>    	- String getNamespacePrefix ()
>>>
>>>The rationale behind OMNamespace extends OMNode is that, we store
>>Namespaces
>>>in the element as a linked list. I agree that this extending from some
>>what
>>>weird OMNode. I think the name is not correct. We want to have
>>>getNextSibling, insertSibling etc., to OMNamespace as well.
>>>One must agree that OMNamespace *MUST* have getNextSibling, insertSibling
>>>etc.,
>>>
>>>
>>i disagree with this assumption - if most of access is through iterators
>>then next/prevSibling is not needed.

[Chinthaka] I think I have to reconsider this. 
How about the parent element having a vector sort of something to hold
namespace declarations, rather than having a linked list of OMNamespace.
So we have an enumerated class called OMNamespace, which has only uri and
prefix as attributes and getters and setters for that.


I have another small problem, if someone need to get all the namespace
declarations an Element has, how can we provide it ? This will be used by
the Serialiser, as we thought of keeping serialisers out of OM. (if this is
also debatable, just defer that and assume as it).

Then how serialiser will get all the namespaces is that 
	Iterator namespaceIter = element.getNamespaceDeclarations();
	While(namespaceIter.hasNext()){
		OMNamespace namespace = (OMNamespace) namespaceIter.next();
		
	}

So, is this OK ? and this required we need an interface for Namespaces,
which we can "hide".


Regards,
Eran Chinthaka
>>
>>>Thoughts and Comments ??
>>>
>>>
>>check XB1 to see how it can be implemented more lightweight without need
>>to have OmNode.
>>
>>my .02c
>>
>>thanks,
>>
>>alek
>>
>>--
>>The best way to predict the future is to invent it - Alan Kay
>>




Re: [Axis2][OM] Simpler way to get NameSpace

Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Eran Chinthaka wrote:

>Oh, I think I missed a lot, just being absent for one day. 
>
>BTW : Let me answer the questions, even though I'm bit late. I might have
>missed some mails, if yes, please forgive me.
>
>To start with I don't that much understand why Srinath wanna remove
>OMNamespace from the API and "Hide" it. Has it committed a crime ?? :)
>  
>
bad bad namespaces let remove them and if not at least let hide them ;-)

unfortunately if you hide OmNamespace you loose opportunities to make OM 
more lightweight and faster - for example you can optimize OM impl so it 
avoid creation of duplicate OmNamespace(prefix, uri) so then you have 
essentially interned it and as for String.intern() you can use fast == 
instead of equals() besides it makes API easier if you have OmNamespace 
when you do operations on *namespaces*...

>First I will explain the rationale behind some namespace methods in
>OMElement.
>
>	The resolveNamespace(uri, prefix) is there to check whether there
>are any namespaces already created with the given info. 
>The reason behind having this is that, one can avoid having two namespaces
>with same uri and prefix. I think as Sanjiva suggested
>resolveNamespace(prefix) should also be there.
>But according to what Alek said, I agree that this should be
>resolveNamespace(uri). But this means, there can be two (or more) namespace
>with different prefixes, but same URI ? Do we wanna allow that ??
>  
>
that is legal in XML 1.0 with namespaces? so API should allow it ...

>	The createNamespace(uri, prefix) - I agree to rename this as
>declareNamespace :)
>
>And I agree that OMNamespace must have following methods.
>	- String getNamespaceName ()
>    	- String getNamespacePrefix ()
>
>The rationale behind OMNamespace extends OMNode is that, we store Namespaces
>in the element as a linked list. I agree that this extending from some what
>weird OMNode. I think the name is not correct. We want to have
>getNextSibling, insertSibling etc., to OMNamespace as well. 
>One must agree that OMNamespace *MUST* have getNextSibling, insertSibling
>etc.,
>  
>
i disagree with this assumption - if most of access is through iterators 
then next/prevSibling is not needed.

>Thoughts and Comments ??
>  
>
check XB1 to see how it can be implemented more lightweight without need 
to have OmNode.

my .02c

thanks,

alek

-- 
The best way to predict the future is to invent it - Alan Kay


RE: [Axis2][OM] Simpler way to get NameSpace

Posted by Eran Chinthaka <ch...@opensource.lk>.
Oh, I think I missed a lot, just being absent for one day. 

BTW : Let me answer the questions, even though I'm bit late. I might have
missed some mails, if yes, please forgive me.

To start with I don't that much understand why Srinath wanna remove
OMNamespace from the API and "Hide" it. Has it committed a crime ?? :)

First I will explain the rationale behind some namespace methods in
OMElement.

	The resolveNamespace(uri, prefix) is there to check whether there
are any namespaces already created with the given info. 
The reason behind having this is that, one can avoid having two namespaces
with same uri and prefix. I think as Sanjiva suggested
resolveNamespace(prefix) should also be there.
But according to what Alek said, I agree that this should be
resolveNamespace(uri). But this means, there can be two (or more) namespace
with different prefixes, but same URI ? Do we wanna allow that ??
	The createNamespace(uri, prefix) - I agree to rename this as
declareNamespace :)

And I agree that OMNamespace must have following methods.
	- String getNamespaceName ()
    	- String getNamespacePrefix ()

The rationale behind OMNamespace extends OMNode is that, we store Namespaces
in the element as a linked list. I agree that this extending from some what
weird OMNode. I think the name is not correct. We want to have
getNextSibling, insertSibling etc., to OMNamespace as well. 
One must agree that OMNamespace *MUST* have getNextSibling, insertSibling
etc.,

Thoughts and Comments ??


Thankx and regards,
-- Eran Chinthaka