The document function does not accept a variable as its argument

VERIFIED FIXED

Status

()

Core
XSLT
P3
normal
VERIFIED FIXED
16 years ago
15 years ago

People

(Reporter: Simon Pepping, Assigned: peterv)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221
BuildID:    2001122108

When the document function is called with a string as its argument it works
fine. When it is called with a variable as its argument, it returns an empty
node set.

Reproducible: Always
Steps to Reproduce:
1.Open bug4.xml in the browser.
2.
3.

Actual Results:  String argument: Number of xml files: 1
Variable: bug4a.xml
Variable as argument: Number of xml files: 0

Expected Results:  String argument: Number of xml files: 1
Variable: bug4a.xml
Variable as argument: Number of xml files: 1
(Reporter)

Comment 1

16 years ago
Created attachment 62699 [details]
attaching stylesheet for verification, bug4.xsl
(Reporter)

Comment 2

16 years ago
Created attachment 62700 [details]
xml file for verification: bug4.xml
(Reporter)

Comment 3

16 years ago
Created attachment 62701 [details]
xml file included by the document function: bug4a.xml
Status: UNCONFIRMED → NEW
Ever confirmed: true
Neat. The problem is that the variable-value is an RTF, which we currently 
handle as a nodeset. And since the nodes in the RTF nodeset don't really have 
any baseURIs (which could be discussed if they should) the uri "bug4a.xml" 
isn't resolved to the right absolute URL. So the fix is to implement RTFs 
correctly.

There are however plenty of workarounds until that is done. Either make sure 
that you convert the argument to a string (ugly) by doing

document(string($xmlfile))
instead of
document($xmlfile)

or make sure that the variable contains a string instead of a RTF (nice) by 
doing

<xsl:param name="xmlfile" select="'bug4a.xml'"/>
instead of
<xsl:param name="xmlfile">bug4a.xml</xsl:param>

Simon: These are great testcases, but it would be greatly appritiated if you 
follow the guidelines at http://www.mozilla.org/projects/xslt/ when attaching 
testcases. See attachments in bug 88745 for reference.

Comment 5

16 years ago
Jonas, I'm not really happy with your explanation. We don't have a second 
argument to the document() function, so the baseURI should be taken from the
xsl:value-of node. (The code doesn't do that right for a nodeset, I think)
I can't try that, but if we'd use mDefResolveNode in 
http://lxr.mozilla.org/seamonkey/source/extensions/transformiix/source/xslt/functions/DocumentFunctionCall.cpp#112
that might do the trick
If there is only one argument and that argument is a nodeset then the baseURI 
should be taken from the .baseURI of the nodes in that nodeset.
now that our variable handling is decent we can fix this
Assignee: keith → sicking
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.2beta

Updated

15 years ago
Blocks: 174372

Comment 8

15 years ago
workarounds noted above didn't help me, but switching from

<xsl:variable name="strlib" select="document(concat($lang, '.xml'))/messages"/>
to
<xsl:variable name="strlib" select="document(concat($lang, '.xml'), /)/messages"/>

fixed it for me.
Note that 

document(concat($lang, '.xml'))

makes the url relative to the XSLT document, whereas

document(concat($lang, '.xml'), /)

makes the url relative to the source document. This is per specification. If
that's not the case please file a separate bug.
Blocks: 179720
No longer blocks: 174372
*** Bug 192072 has been marked as a duplicate of this bug. ***
This will be fixed with petervs RTF-patch
Assignee: bugmail → peterv
Status: ASSIGNED → NEW
Clearing milestone since 1.2beta happened a long time ago.
Target Milestone: mozilla1.2beta → ---

Comment 13

15 years ago
fixed by rtf landing
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 14

15 years ago
mass verifying
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.