axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eran Chinthaka" <>
Subject RE: [Axis2][OM] Simpler way to get NameSpace
Date Fri, 10 Dec 2004 05:53:40 GMT

>>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
>>>	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
>>>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)
>>>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
>>>in the element as a linked list. I agree that this extending from some
>>>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
>>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();
		OMNamespace namespace = (OMNamespace);

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

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

View raw message