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 Boris Kolpackov <bo...@codesynthesis.com> on 2008/06/19 15:24:18 UTC
Merging DOMXPathResult and DOMXPath2Result
Hi John,
I went ahead and merged the two interfaces. Could you please
review the result (and notes below) to see if it's good enough
for XQilla:
http://codesynthesis.com/~boris/tmp/DOMXPathResult.hpp
The overall goal of the merger is to come up with an interface that
can serve both XPath 1.0 and XPath 2.0 (so that we can return
DOMXPathResult* instead of void* from DOMXPathExpression::evaluate())
even though the semantic can be quite different in some cases
(e.g., XPath 2.0 can have a result which is a sequence of strings
while XPath 1.0 can only have a sequence of nodes).
Here is a list of changes:
- add FIRST_RESULT, ITERATOR_RESULT, and SNAPSHOT_RESULT to
resultType enum
- add getTypeInfo()
- add NO_RESULT_ERROR code to DOMXPathException which is used
instead of INVALID_STATE_ERR in get*Value() function.
- add getIntegerValue()
- rename getSingleNodeValue() to getNodeValue()
- change iterateNext() and snapshotItem () to return bool instead
of const DOMNode*
I also left out the isNode() function that is present in DOMXPath2Result.
I am not sure it is needed (and if it is, why there is no isBoolen(),
isString(), etc.).
Finally, I am wondering why the DOM node returned by getNodeValue()
(and asNode()) is const? Finding nodes with XPath and then modifying
them sounds like a perfectly reasonable idea (in fact not long ago I
wrote a small XML Scheam simplifier which needed this so I had to
resort to const_cast). Plus it is fairly easy to "break out" of
constness in DOM (e.g., getParentNode() is const and returns non-
const node). Are there any problems with returning non-const node?
Thanks,
Boris
--
Boris Kolpackov, Code Synthesis Tools http://codesynthesis.com/~boris/blog
Open source XML data binding for C++: http://codesynthesis.com/products/xsd
Mobile/embedded validating XML parsing: http://codesynthesis.com/products/xsde
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Merging DOMXPathResult and DOMXPath2Result
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi John,
John Snelson <jo...@oracle.com> writes:
> Note that XPath 2.0 implementations ought to be able to give meaningful
> results to a request for any of the resultType enumerations types.
Hm, this looks like a pretty hard thing to achieve since the models
are so different. I initially thought about mapping XPath 2 result
types to XPath 1 ones but that does not seem possible (e.g., you
cannot map ITERATOR_RESULT to, say, UNORDERED_NODE_ITERATOR_TYPE
because the latter can only contain nodes and the former can result
in a sequence with various types).
So I simply added the XPath 2 result types into the enum and marked
the old ones as XPath 1 and the new ones as XPath 2. I think it is
ok for an XPath 2 implementation not to support the XPath 1 result
types.
(BTW, I just noticed the _TYPE suffix inconsistency so I am going
to add it to the XPath 2 enumerators).
> isNode() is needed because the DOMTypeInfo does not provide a way to
> distinguish between a node of type xs:string and a value of type
> xs:string.
Ok, I will add isNode().
Thanks,
Boris
--
Boris Kolpackov, Code Synthesis Tools http://codesynthesis.com/~boris/blog
Open source XML data binding for C++: http://codesynthesis.com/products/xsd
Mobile/embedded validating XML parsing: http://codesynthesis.com/products/xsde
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Merging DOMXPathResult and DOMXPath2Result
Posted by John Snelson <jo...@oracle.com>.
Hi Boris,
Those changes look good as far as I can see. Note that XPath 2.0
implementations ought to be able to give meaningful results to a request
for any of the resultType enumerations types.
Boris Kolpackov wrote:
> I went ahead and merged the two interfaces. Could you please
> review the result (and notes below) to see if it's good enough
> for XQilla:
>
> http://codesynthesis.com/~boris/tmp/DOMXPathResult.hpp
>
> The overall goal of the merger is to come up with an interface that
> can serve both XPath 1.0 and XPath 2.0 (so that we can return
> DOMXPathResult* instead of void* from DOMXPathExpression::evaluate())
> even though the semantic can be quite different in some cases
> (e.g., XPath 2.0 can have a result which is a sequence of strings
> while XPath 1.0 can only have a sequence of nodes).
>
> Here is a list of changes:
>
> - add FIRST_RESULT, ITERATOR_RESULT, and SNAPSHOT_RESULT to
> resultType enum
>
> - add getTypeInfo()
>
> - add NO_RESULT_ERROR code to DOMXPathException which is used
> instead of INVALID_STATE_ERR in get*Value() function.
>
> - add getIntegerValue()
>
> - rename getSingleNodeValue() to getNodeValue()
>
> - change iterateNext() and snapshotItem () to return bool instead
> of const DOMNode*
>
> I also left out the isNode() function that is present in DOMXPath2Result.
> I am not sure it is needed (and if it is, why there is no isBoolen(),
> isString(), etc.).
isNode() is needed because the DOMTypeInfo does not provide a way to
distinguish between a node of type xs:string and a value of type xs:string.
> Finally, I am wondering why the DOM node returned by getNodeValue()
> (and asNode()) is const? Finding nodes with XPath and then modifying
> them sounds like a perfectly reasonable idea (in fact not long ago I
> wrote a small XML Scheam simplifier which needed this so I had to
> resort to const_cast). Plus it is fairly easy to "break out" of
> constness in DOM (e.g., getParentNode() is const and returns non-
> const node). Are there any problems with returning non-const node?
I think returning a non-const node would be fine.
John
--
John Snelson, Oracle Corporation http://snelson.org.uk/john
Berkeley DB XML: http://oracle.com/database/berkeley-db/xml
XQilla: http://xqilla.sourceforge.net
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org