You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by Gareth Reakes <ga...@decisionsoft.com> on 2002/08/07 12:17:58 UTC
compareTreePosition problems
Hi all,
I'm implementing compareTreePosition and have come across some
problems that I cannot think of a clean way to solve. I was just going to
go and port the java code but unfortunately they do not implement the
extendability feature. I require this for the XPath namespace node.
The spec says
Compares a node with this node with regard to their position in the
tree and according to the document order. This order can be
extended by module that define additional types of nodes.
(the typo is in the spec)
OK. So for all normal nodes (ie defined in DOM Level 1) the
compareTreeMethod in DOMNodeImpl will take care of this. The problem
arises when adding new node types. The only way I can see of doing it is
to insist that the writer of the newest node caters for comparison to all
other node types. The node would provide 2 methods
compareMeToOther(DOMNode *other)
compareOtherToMe(DOMNode *other)
The compareTreePostition would check to see if the DOMNodes it is checking
are standard (ie value 12 or less) and if not then delegate to the
appropriate method. The problem then is which to you delegate to? Only the
newest one will have all the comparisons in. You could put a check in a
the beginning of each of these methods to see if it deals with this node
type and if not then delegate it further. Or you could just pass the call
from compareTreePosition to the node with the largest node value something
like this
short thisType = getNodeType();
short otherType = other->getNodeType();
if(thisType > 12 | otherType > 12) {
return thisType > otherType ? compareOtherToMe(other) :
other->compareMeToOther(this);
}
but then we will have to enforce (hope?) that the node with the biggest
value is in fact the newest one.
Any preferences (or new ideas)?
Gareth
--
Gareth Reakes, Head of Product Development
DecisionSoft Ltd. http://www.decisionsoft.com
Office: +44 (0) 1865 203192
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: compareTreePosition problems
Posted by Gareth Reakes <ga...@decisionsoft.com>.
Hi Tinny,
thanks for the reply. I do agree with you. One of the methods I
described was going to just reverse the result and be implemented in
DOMNodeImpl. I thought about creating a different method for compare as
some tests (like node equality) are the same for every implementation and
could always happen in the compareTreePosition in DOMNodeImpl.
We will still have to enforce that the largest value of type is
the "newest". The problem arises when both the nodes are bigger than 12.
Say we have a node with value 14. Its compareTreePosition could have a
similar clause to the one you defined
short DOMXXXImpl::compareTreePosition(DOMNode*
other)
{
short otherType = other->getNodeType();
if (otherType <= 14)
{
//our node comparison code
}
else {
other->compareTreePosition(this);
//reverse this now
}
Are we happy with saying that the largest value is the "newest"? I fear
that someone may come along and say "Ill set mine to 99 because that wont
conflict with anyone elses". What do you think?
Gareth
On Wed, 7 Aug 2002, Tinny Ng wrote:
> Gareth,
>
> To support extendability, we need to care about two cases:
> 1. thisType > 12
> 2. otherType > 12
>
> For thisType > 12, the implementer of the new extended node should overwrite
> the virtual function and implement its own compareTreePosition logic. Thus
> DOMNodeImpl::compareTreePosition shouldn't be reached.
>
> e.g.
> short DOMMyOwnNodeImpl::compareTreePosition(DOMNode* other)
> {
> // should not call fNode.compareTreePosition(other);
> // should have its own logic
> :
> :
> };
>
> So the DOMNodeImpl::compareTreePosition should only worry the second case,
> i.e. if the parameter "other" has type > 12.
>
> To deal with this, I would suggest we call the
> DOMMyOwnNodeImpl::compareTreePosition to get the order the other way round,
> then reverse it. e.g.
>
> short DOMNodeImpl::compareTreePosition(DOMNode* other)
> {
> short otherType = other->getNodeType();
> if (otherType <= 12)
> {
> // code port from Xerces-J
> :
> }
> else {
> short position =
> other->compareTreePosition(this);
> if (position == TREE_POSITION_PRECEDING)
> position = TREE_POSITION_FOLLOWING;
> else if (position == TREE_POSITION_FOLLOWING)
> position = TREE_POSITION_PRECEDING;
> return position;
> }
> }
>
> So I think only one function compareTreePosition should be enough, not
> really need "compareMeToOther" nor "compareOtherToMe".
>
> What do you think?
>
> Tinny
>
> ----- Original Message -----
> From: "Gareth Reakes" <ga...@decisionsoft.com>
> To: <xe...@xml.apache.org>
> Sent: Wednesday, August 07, 2002 6:17 AM
> Subject: compareTreePosition problems
>
>
> > Hi all,
> > I'm implementing compareTreePosition and have come across some
> > problems that I cannot think of a clean way to solve. I was just going to
> > go and port the java code but unfortunately they do not implement the
> > extendability feature. I require this for the XPath namespace node.
> >
> >
> > The spec says
> >
> > Compares a node with this node with regard to their position in the
> > tree and according to the document order. This order can be
> > extended by module that define additional types of nodes.
> >
> > (the typo is in the spec)
> >
> >
> > OK. So for all normal nodes (ie defined in DOM Level 1) the
> > compareTreeMethod in DOMNodeImpl will take care of this. The problem
> > arises when adding new node types. The only way I can see of doing it is
> > to insist that the writer of the newest node caters for comparison to all
> > other node types. The node would provide 2 methods
> >
> > compareMeToOther(DOMNode *other)
> > compareOtherToMe(DOMNode *other)
> >
> >
> > The compareTreePostition would check to see if the DOMNodes it is checking
> > are standard (ie value 12 or less) and if not then delegate to the
> > appropriate method. The problem then is which to you delegate to? Only the
> > newest one will have all the comparisons in. You could put a check in a
> > the beginning of each of these methods to see if it deals with this node
> > type and if not then delegate it further. Or you could just pass the call
> > from compareTreePosition to the node with the largest node value something
> > like this
> >
> > short thisType = getNodeType();
> > short otherType = other->getNodeType();
> >
> > if(thisType > 12 | otherType > 12) {
> > return thisType > otherType ? compareOtherToMe(other) :
> > other->compareMeToOther(this);
> > }
> >
> > but then we will have to enforce (hope?) that the node with the biggest
> > value is in fact the newest one.
> >
> > Any preferences (or new ideas)?
> >
> > Gareth
> >
> >
> >
> > --
> > Gareth Reakes, Head of Product Development
> > DecisionSoft Ltd. http://www.decisionsoft.com
> > Office: +44 (0) 1865 203192
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
--
Gareth Reakes, Head of Product Development
DecisionSoft Ltd. http://www.decisionsoft.com
Office: +44 (0) 1865 203192
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: compareTreePosition problems
Posted by Tinny Ng <tn...@ca.ibm.com>.
Gareth,
To support extendability, we need to care about two cases:
1. thisType > 12
2. otherType > 12
For thisType > 12, the implementer of the new extended node should overwrite
the virtual function and implement its own compareTreePosition logic. Thus
DOMNodeImpl::compareTreePosition shouldn't be reached.
e.g.
short DOMMyOwnNodeImpl::compareTreePosition(DOMNode* other)
{
// should not call fNode.compareTreePosition(other);
// should have its own logic
:
:
};
So the DOMNodeImpl::compareTreePosition should only worry the second case,
i.e. if the parameter "other" has type > 12.
To deal with this, I would suggest we call the
DOMMyOwnNodeImpl::compareTreePosition to get the order the other way round,
then reverse it. e.g.
short DOMNodeImpl::compareTreePosition(DOMNode* other)
{
short otherType = other->getNodeType();
if (otherType <= 12)
{
// code port from Xerces-J
:
}
else {
short position =
other->compareTreePosition(this);
if (position == TREE_POSITION_PRECEDING)
position = TREE_POSITION_FOLLOWING;
else if (position == TREE_POSITION_FOLLOWING)
position = TREE_POSITION_PRECEDING;
return position;
}
}
So I think only one function compareTreePosition should be enough, not
really need "compareMeToOther" nor "compareOtherToMe".
What do you think?
Tinny
----- Original Message -----
From: "Gareth Reakes" <ga...@decisionsoft.com>
To: <xe...@xml.apache.org>
Sent: Wednesday, August 07, 2002 6:17 AM
Subject: compareTreePosition problems
> Hi all,
> I'm implementing compareTreePosition and have come across some
> problems that I cannot think of a clean way to solve. I was just going to
> go and port the java code but unfortunately they do not implement the
> extendability feature. I require this for the XPath namespace node.
>
>
> The spec says
>
> Compares a node with this node with regard to their position in the
> tree and according to the document order. This order can be
> extended by module that define additional types of nodes.
>
> (the typo is in the spec)
>
>
> OK. So for all normal nodes (ie defined in DOM Level 1) the
> compareTreeMethod in DOMNodeImpl will take care of this. The problem
> arises when adding new node types. The only way I can see of doing it is
> to insist that the writer of the newest node caters for comparison to all
> other node types. The node would provide 2 methods
>
> compareMeToOther(DOMNode *other)
> compareOtherToMe(DOMNode *other)
>
>
> The compareTreePostition would check to see if the DOMNodes it is checking
> are standard (ie value 12 or less) and if not then delegate to the
> appropriate method. The problem then is which to you delegate to? Only the
> newest one will have all the comparisons in. You could put a check in a
> the beginning of each of these methods to see if it deals with this node
> type and if not then delegate it further. Or you could just pass the call
> from compareTreePosition to the node with the largest node value something
> like this
>
> short thisType = getNodeType();
> short otherType = other->getNodeType();
>
> if(thisType > 12 | otherType > 12) {
> return thisType > otherType ? compareOtherToMe(other) :
> other->compareMeToOther(this);
> }
>
> but then we will have to enforce (hope?) that the node with the biggest
> value is in fact the newest one.
>
> Any preferences (or new ideas)?
>
> Gareth
>
>
>
> --
> Gareth Reakes, Head of Product Development
> DecisionSoft Ltd. http://www.decisionsoft.com
> Office: +44 (0) 1865 203192
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org