RE: SQL and XPath Problem?

art_w Tue, 26 Nov 2002 11:24:47 -0800

Title: Message

Actually I would have to disagree with you.

According to the DOM specifications the NAME of an element node should be the node name and the VALUE should be null.

In this case the child of the element node would be a text node that would have NAME="#text" and the VALUE would be the contents of the text node.

From the DOM specifications:

The values of nodeName, nodeValue, and attributes vary according to the node type as follows:

Interface	nodeName	nodeValue	attributes
Attr	name of attribute	value of attribute	null
CDATASection	#cdata-section	content of the CDATA Section	null
Comment	#comment	content of the comment	null
Document	#document	null	null
DocumentFragment	#document-fragment	null	null
DocumentType	document type name	null	null
Element	tag name	null	NamedNodeMap
Entity	entity name	null	null
EntityReference	name of entity referenced	null	null
Notation	notation name	null	null
ProcessingInstruction	target	entire content excluding the target	null
Text	#text	content of the text node	null

According to the XPath specifications "The string-value of an element node is the concatenation of the string-values of all text node descendants of the element node in document order." (5.2)

Also in section 4.2 the XPath string() function states "A node-set is converted to a string by returning the string-value of the node in the node-set that is first in document order."

I am beginning to gain an understanding of the DTM stuff. I am still researching. But I can see where DOM2DTM in it's getStringValue() function checks the type of the node and if it is ELEMENT_NODE, DOCUMENT_NODE or DOCUMENT_FRAGMENT_NODE then it calls getNodeData() which recursively processes the child nodes and obtains the text.

I want to do a bit more research, and some testing, but I expect that I will be proposing a patch to do basically the same thing in DTMDocument. It should not be necessary to access the text of an element explicitly. Fortunately I do not think that this change would break any existing code that may be doing that. I was wondering how other people could be using the SQL extension for much, with this problem... but if everyone is explicitly getting the text that could do it. If I am understanding the spec correctly though, should not be necessary... and I can not help but feel that it could cause other problems or difficulties if XPath is used much with the SQL results.

Art

-----Original Message-----
From: John Gentilin [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 26, 2002 2:03 PM
To: [EMAIL PROTECTED]
Subject: Re: SQL and XPath Problem?

Art,
The behavior you describe is the behavior that is programmed into
the SQL extension. As far as I know, I am supplying the correct values
as per the spec, if this is not true we can change it.
With you desc2 element, you are asking for the string value of an Element
Node and not the child text node. Element nodes have a default value of
#element and text nodes have a default name of #text.
To make this work, you need to apply the text() axis function to pass the
value of the text element to the String function i.e.
<desc2><xsl:value-of select="string($queryresult/sql/row-set/row/col[1]/text())"/></desc2>
Regards
John G
[EMAIL PROTECTED] wrote:

Before I enter it into Bugzilla as a bug, I figure that I will run this by the Xalan group. I have been trying to figure this out for a while - with no success.
I have been doing some work with the SQL extension. I have encountered what appears to be a bug. When I attempt to use the results of an SQL query in some XPath expressions it fails. It looks like it may be things that involve conversion of the result to a string. For example the following stylesheet:
<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                version="1.0"
                xmlns:sql="org.apache.xalan.lib.sql.XConnection"
                extension-element-prefixes="sql">
<xsl:param name="query" select="'SELECT short_description FROM bkparama WHERE groupid = 25 and ordinal = 1'"/>
<xsl:template match="/">
<root>
    
    <xsl:variable name="connection2"
                  select="sql:new('com.sybase.jdbc2.jdbc.SybDriver',
                                'jdbc:sybase:Tds:dev1:1234/teller', 'user', 'password')"/>
        <xsl:variable name="queryresult" select="sql:query($connection2, $query)"/>
        <desc1><xsl:value-of select="$queryresult/sql/row-set/row/col[1]"/></desc1>
        <desc2><xsl:value-of select="string($queryresult/sql/row-set/row/col[1])"/></desc2>
        <desc3><xsl:value-of select="$queryresult/sql/row-set/row/col[1]"/></desc3>
        
        <xsl:value-of select="sql:close($connection2)"/>
</root>
</xsl:template>
</xsl:stylesheet>
Produces the following output:
<?xml version="1.0" encoding="UTF-8"?>
<root><desc1>Curr Proc Date</desc1><desc2>#element</desc2><desc3>Curr Proc Date</desc3></root>
As you can see, the output appears to be correct except when the XPath string() function is invoked on the column. In this case it is giving the type of the node instead of the content of the node.
I have backed into this so far as to see that in FunctionDef1Arg.getArg0AsString() it is getting a NodeSet as the argument. This nodeset when converted to a string gives "#element". It appears to be because nodelist().item(0) of this nodeset gives "#element" for getNode Value() (getNodeName() = "col"). If this is DOM, I would expect an element node to have NULL for the value. Pursuing this further, I can getFirstChild() on this node and for this I get getNodeName()="#text" and getNodeValue()="The text I want".
The next stop on my journey through the code was in DTMDocument.getStringValue() because this is invoked by XNodeSet.getStringFromNode(). The DTMDocument.getStringValue() function obtains an object from m_ObjectArray. This object turns out to be the java.lang.String "#element". Unfortunately at this point I am a bit stuck. Here it appears to get into some DTM stuff that I have not figured out yet. I am hoping that someone can point out some glaring problem with what I am doing that I am completely missing, or point me in the right direction anyway.
Alternatively if someone can confirm that this is a bug and not just a misunderstanding on my part, I will enter it into Bugzilla - and/or try to resolve it myself and submit a patch.
Thank You,
Art

--
--------------------------------------
John Gentilin
Eye Catching Solutions Inc.
18314 Carlwyn Drive
Castro Valley CA 94546
    Contact Info
[EMAIL PROTECTED]
Ca Office 1-510-881-4821
NJ Office 1-732-422-4917

RE: SQL and XPath Problem?

Reply via email to