On 01/19/2012 04:00 PM, Michael Kay wrote:
> On 19/01/2012 14:33, Johannes.Lichtenberger wrote:
>> On 01/19/2012 01:24 PM, Michael Kay wrote:
>>> On 19/01/2012 12:04, Johannes.Lichtenberger wrote:
>>>> On 01/19/2012 12:50 PM, Johannes.Lichtenberger wrote:
>>>>> I haven't used Saxon for a while, but I'm currently replacing our own
>>>>> XPath-Engine in my GUI with the Saxon-integration I've developed some
>>>>> time ago.
>>>>> I want to retrieve the underlying NodeInfo implementation of an XdmItem
>>>>> to get the nodeKeys (unique IDs) of the results if it's a node, but I
>>>>> don't know how.
>>>> Ok, just learned, that I can cast a ValueRepresentation to the wrapped
>>>> NodeInfo implementation if it's an instance of NodeInfo.
>>> Also, if the XdmItem is an XdmNode, then you can call
>>> getUnderlyingNode() to get the corresponding NodeInfo.
>> Hm, strange, the returned result for instance is of type TinyElementImpl.
> Sure, that's one of many concrete classes that implements the NodeInfo
> interface. Generally, you shouldn't care what the implementation class is.
Hm, ok, but I think it has to use my NodeInfo implementation for the
results as well, as it seems it first of all constructed the tree in
memory based on our NodeInfo implementation and the result is correct
(but with your TinyTree implementation instead of our NodeInfo-Impl.).
However it also seems to construct the whole tree in memory for a query
lik "/element". I suppose the query should just touch the document- and
the root element-node.
Maybe it's possible to not create the DocumentBuilder:
final DocumentBuilder builder = proc.newDocumentBuilder();
and to get an XdmItem instance from our NodeInfo-implementation directly
to provide it as the document root context item?
Or maybe I just misunderstood something, as I'm not really into
>> I suppose in order to not construct the whole tree-representation at
>> once I have to implement ExternalObjectModel? We use a persistent
>> tree-structure and cache some NodePages with the actual Nodes in memory,
>> but not the whole tree to support very large instances and all kinds of
>> update operations.
> Well, the main requirement is to implement NodeInfo, but if you
> implement ExternalObjectModel as well, that provides some extra value,
> e.g. when calling extension functions.
Seems we don't need to implement it, as we use the Personal Edition I
think (the Open Source version) and I think it would be great to support
at least XPath 2.0 (and optionally XQuery 1.0/XSLT 2.0 via Saxon)
without winning any performance tests, but just that it's usable even on
large XML instance ranging from several 100MB to maybe a few Gb.
If someone intends to use our open source product sometime :D