Ok.  I am starting to think that my confusion is related to Stylus Studio handling of parameters.  For the .Net code it is apparent that there is a document element or a sequence of document elements.  That is why $bookSets/Books[@Genre = $genreName] works.  This is what I would expect.

However in the Stylus Studio, using "document(...) | document(...)" in the scenario parameter, I have to use the following: $bookSets[@Genre = $genreName] to bring back the appropriate elements. This is why I thought earlier there is only a comment node and two element nodes.  It is almost as if Stylus Studio is tacking on the /child::node().

Correct me if I am wrong but this must be "Result Tree Fragment" v.s. node list.  Stylus parameters seem to be fix to "Result Tree Fragment".


On 1/3/07, Michael Kay <mike@saxonica.com> wrote:

I meant for the XML example to show the result of the union of two documents results in a comment node and two elements.  I apologize for the confusion. 
How can the union of two documents result in a comment node and two elements? You can only get that if you find the children of the document nodes, for example (document('a')|document('b'))/child::node().

For the .Net code, I populated a List<XdmNode> with two XdmNodes created using a document builder.  I then create XdmValue taking the List<XdmNode> as the argument.  And then I pass that XdmValue into setParameter.   
If you do this, the value of the parameter will be a sequence containing two document nodes.
 I was hoping it would be the equivalent of "document(...) | document(..)".   
It is. The document() function returns a document node, the union of two document nodes is a sequence of length two (assuming they are distinct documents, of course), and the items in that sequence are document nodes.
In either case, if you want the children of the document nodes, you need to navigate to find them, either at the application level or within the called stylesheet.
Did I misunderstand your suggestion earlier on how to set a node-sequence to a parameter?

Yes, I think you have some basic misunderstanding of the data model, and I'm not quite sure where the problem lies. Though it's true that many people find document nodes confusing because they are invisible in lexical XML.
Michael Kay

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash

saxon-help mailing list

John Cavalieri