Nabble - Xalan

Re: Newbie questions regarding evaluating XPath using an arbitrary Xerces DOMElement as the context node

2009-12-07T11:55:09Z

>
> I've looked over the relevant samples and documentation, but haven't
> found enough information. Any pointers to useful doc or samples would
> be appreciated.
> In fact, the samples and documentation lead me to additional questions:
>
> From the XercesParserLiaison API, it would appear that I need
> buildMaps=true, and possibly buildWrapper=true, in order to map the
> Xerces DOMNode to its Xalan counterpart, but I don't see any method that
> uses the map to give me the Xalan node from the Xerces node.

buildWrapper determines if the wrapper is built all at once or as each
node is accessed. And although it's not explicitly documented, I
believe asking for the maps will force the wrapper to be built.

To get at mapping information, you must cast the XalanDocument pointer
to the implementation type of XercesDocumentWrapper, and include the
header file for that class:

DOMNode* func(XalanDocument* doc, XalanNode* node)
{
const XercesDocumentWrapper* wrapper = static_cast<const
XercesDocumentWrapper*>(doc);

return wrapper->mapNode(node);
}

XalanNode* func(XalanDocument* doc, DOMNode* node)
{
const XercesDocumentWrapper* wrapper = static_cast<const
XercesDocumentWrapper*>(doc);

return wrapper->mapNode(node);
}

>
> What is the overhead of enabling buildWrapper and buildMaps?
> Are they kept current across modifications to the original Xerces DOM?
The overhead is the memory required to maintain the wrapper and the hash
maps of the nodes. This can be significant if your document is large.

The wrapper and the maps are _not_ maintained across modifications to
the Xerces DOM. Not only would it be complicated, but I'm not sure how
it's possible to track modifications to the Xerces DOM instance.

>
> From a sample, I have:
> // Set up our link between the Xerces and Xalan DOMs. (doc is a
> Xerces DOMDocument*)
> XercesDOMSupport support;
> XercesParserLiaison liaison(support);
> XercesDOMWrapperParsedSource src(doc, liaison, support);
> XalanDocument* xalanDoc = src.getDocument( );
>
> Yet it would appear from the API that I could pare that down to:
> // Set up our link between the Xerces and Xalan DOMs. (doc is a
> Xerces DOMDocument*)
> XercesDOMSupport support;
> XercesParserLiaison liaison(support);
> XalanDocument* xalanDoc = liaison.createDocument(doc, false, true,
> true);
>
> Are these equivalent, or is there a reason to use one over the other?
> If I use XercesDOMWrapperParsedSource, do I need to set properties of
> liaison first to force mapping and wrapping?

You would only want to use a XercesDOMWrapperParsedSource if you plan to
use the XalanTransformer class to transform the document. Otherwise, if
you're using only the XPathEvaluator API, you can simply use the
XalanDocument instance returned from XercesParserLiaison::createDocument().

If you want the maps to be built, you must call
liaison.setBuildMaps(true) before you create the
XercesDOMWrapperParsedSource instance. XercesDOMWrapperParsed source
_forces_ the "threadSafe" and "buildWrapper" parameters to be true when
it calls XercesParserLiaison::createDocument().

>
> If the overhead is significant to wrapping and/or mapping, especially if
> the entire document is processed, I would want to cache them for later
> use evaluating other XPaths.
> Which of the associated objects is sufficient to cache? liason and
> xalanDoc? support?
The XercesParserLiaison owns the XalanDocument instance, so you must
keep that alive. The XalanDocument instance it creates owns the wrapper
and the maps, so you must keep that alive as well. Note that caching is
useless if you plan to modify the Xerces DOM instance.

>
> And finally, how do I map a Xerces DOMNode/DOMElement to a Xalan node to
> use as the context for XPath evaluation?
See the small function snippets I provided previously.

Dave

From forum: Xalan - C - Users

Newbie questions regarding evaluating XPath using an arbitrary Xerces DOMElement as the context node

2009-12-07T09:13:51Z

I've looked over the relevant samples and documentation, but haven't found enough information. Any pointers to useful doc or samples would be appreciated.
In fact, the samples and documentation lead me to additional questions:

From the XercesParserLiaison API, it would appear that I need buildMaps=true, and possibly buildWrapper=true, in order to map the Xerces DOMNode to its Xalan counterpart, but I don't see any method that uses the map to give me the Xalan node from the Xerces node.

What is the overhead of enabling buildWrapper and buildMaps?
Are they kept current across modifications to the original Xerces DOM?

From a sample, I have:
// Set up our link between the Xerces and Xalan DOMs. (doc is a Xerces DOMDocument*)
XercesDOMSupport support;
XercesParserLiaison liaison(support);
XercesDOMWrapperParsedSource src(doc, liaison, support);
XalanDocument* xalanDoc = src.getDocument( );

Yet it would appear from the API that I could pare that down to:
// Set up our link between the Xerces and Xalan DOMs. (doc is a Xerces DOMDocument*)
XercesDOMSupport support;
XercesParserLiaison liaison(support);
XalanDocument* xalanDoc = liaison.createDocument(doc, false, true, true);

Are these equivalent, or is there a reason to use one over the other?
If I use XercesDOMWrapperParsedSource, do I need to set properties of liaison first to force mapping and wrapping?

If the overhead is significant to wrapping and/or mapping, especially if the entire document is processed, I would want to cache them for later use evaluating other XPaths.
Which of the associated objects is sufficient to cache? liason and xalanDoc? support?

And finally, how do I map a Xerces DOMNode/DOMElement to a Xalan node to use as the context for XPath evaluation?

---------------------------------------------------
David S. Johnson
DeskNet Inc.

From forum: Xalan - C - Users

Re: How to achieve in xslt equivalent to xs:any in xerces

2009-12-01T08:13:12Z

> So it seems to mean a new XSLT 2.0 processor has been released about > two weeks ago? > >http://www.ibm.com/common/ssi/rep_ca/1/897/ENUS209-391/ENUS209-391.PDF
Yes, though it's only available as part of the Websphere environment.

(Don't bother asking me whether it will be available through other channels. I honestly don't know, and if I did I couldn't say so anyway.)

______________________________________
"... Three things see no end: A loop with exit code done wrong,
A semaphore untested, And the change that comes along. ..."
-- "Threes" Rev 1.1 - Duane Elms / Leslie Fish (http://www.ovff.org/pegasus/songs/threes-rev-11.html)

Nabble - Xalan

Re: Newbie questions regarding evaluating XPath using an arbitrary Xerces DOMElement as the context node

Newbie questions regarding evaluating XPath using an arbitrary Xerces DOMElement as the context node

Re: How to achieve in xslt equivalent to xs:any in xerces

Re: How to achieve in xslt equivalent to xs:any in xerces

Re: Error in output when xmlns attribute is present

Error in output when xmlns attribute is present

Re: How to achieve in xslt equivalent to xs:any in xerces

Re: How to achieve in xslt equivalent to xs:any in xerces

Re: xml with dots in tags

Re: xml with dots in tags

xml with dots in tags

[jira] Commented: (XALANJ-2510) Ability to set non tree fragment variable using an extension element (PATCH SUPPLIED)

Re: How to achieve in xslt equivalent to xs:any in xerces

Re: How to achieve in xslt equivalent to xs:any in xerces

Re: How to achieve in xslt equivalent to xs:any in xerces

How to achieve in xslt equivalent to xs:any in xerces

[jira] Commented: (XALANJ-2510) Ability to set non tree fragment variable using an extension element (PATCH SUPPLIED)

[jira] Commented: (XALANJ-2510) Ability to set non tree fragment variable using an extension element (PATCH SUPPLIED)

[jira] Resolved: (XALANJ-2495) Corrections to German error messages

[jira] Commented: (XALANJ-2490) Class name derived from namespace URI, not xalan:script element

[jira] Commented: (XALANJ-2473) DTMNodeProxy.getTextContent() does not return text content of child nodes

[jira] Resolved: (XALANJ-2424) set:distinct() over attribute list breaks XSLTC throwing HIERARCHY_REQUEST_ERR

[jira] Resolved: (XALANJ-2493) BasisLibrary.nodeList2Iterator broken

[jira] Commented: (XALANJ-2493) BasisLibrary.nodeList2Iterator broken

[jira] Commented: (XALANJ-2493) BasisLibrary.nodeList2Iterator broken

[jira] Commented: (XALANJ-2493) BasisLibrary.nodeList2Iterator broken

[jira] Commented: (XALANJ-2493) BasisLibrary.nodeList2Iterator broken

Re: Xalan J Future

Re: fo:external-graphic and xml:base

Re: fo:external-graphic and xml:base

[jira] Commented: (XALANJ-2510) Ability to set non tree fragment variable using an extension element (PATCH SUPPLIED)

[jira] Commented: (XALANJ-2510) Ability to set non tree fragment variable using an extension element (PATCH SUPPLIED)

Re: Loosing significant space in LSSerializer

Re: Loosing significant space in LSSerializer

Re: Loosing significant space in LSSerializer