3.5M1 issue with string-join

> I upgraded OPS from 3.0.1 and am trying my application in 3.5M1,  
> but I'm running into a problem.  I believe the XSL string-join  
> function isn't returning things in the same order.
>
> My application makes use of a peer template which governs the order  
> of elements and various UI aspects for controls.  The view for the  
> editor is an XSL stylesheet which walks through the template and  
> reads an "xpath" variable referencing the corresponding elements.  
> Are you still with me?  It's crazy, but it works.
>
> The offending control below fails to display:
>
> <xforms:input ref="xxforms:evaluate(concat('instance(''main-
> instance'')/document/',
>         string-join(xxforms:repeat-current('attribute-repeat-
> {position()}')/ancestor-or-self::*/@xpath, '/')))">
>     <xforms:label ref="xxforms:repeat-current('attribute-repeat-
> {position()}')/label"/>
> </xforms:input>
>
> I did a little debugging with the following to see what xpath was  
> being evaluated:
>
> <xforms:output value="concat('instance(''main-instance'')/document/',
>    string-join(xxforms:repeat-current('attribute-repeat-{position
> ()}')/ancestor-or-self::*/@xpath, '/'))"/>
>
> The output is:
>
> instance('main-instance')/document/@authority//mods:mods/
> mods:titleInfo[1]
>
> However, the right result (which came up with version 3.0.1) is:
>
> instance('main-instance')/document//mods:mods/mods:titleInfo[1]/
> @authority
>
> I've tested the string-join command in oXygen and get the right  
> result.  I only see it incorrect in OPS 3.5M1.  Any suggestions on  
> this are most welcome.
>
> Duane Gran
>
>
> --
> You receive this message as a subscriber of the ops-
> [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/ 
> wws

> All,
>
> I have an update on this issue, but I'm still perplexed.  The error has
> to do with the position() function.  I did some testing with the
> "hello1" and "hello2" tutorial examples and I'm able to reproduce this.  
> See the two attached files.
>
> * view.html is a replacement for the one in examples/tutorial/hello1
> * view.xsl is a replacement for the one in examples/tutorial/hello2
>
> The files are identical, but the first one displays (correctly):
>
>  
> instance('main-instance')/document//mods:mods/mods:titleInfo[1]/@authority
>
> The second one displays (incorrectly):
>
>  instance('main-instance')/document/@authority//mods:mods/mods:titleInfo[1]
>
> Curiously enough, if I load them into the sandbox they both show the
> incorrect output.  Any ideas on this are most appreciated.
>
> Duane Gran
>
>
> On Sep 7, 2006, at 4:24 PM, Duane Gran wrote:
>
>> I upgraded OPS from 3.0.1 and am trying my application in 3.5M1, but
>> I'm running into a problem.  I believe the XSL string-join function
>> isn't returning things in the same order.
>>
>> My application makes use of a peer template which governs the order of
>> elements and various UI aspects for controls.  The view for the editor
>> is an XSL stylesheet which walks through the template and reads an
>> "xpath" variable referencing the corresponding elements.  Are you
>> still with me?  It's crazy, but it works.
>>
>> The offending control below fails to display:
>>
>> <xforms:input
>> ref="xxforms:evaluate(concat('instance(''main-instance'')/document/',
>>        
>> string-join(xxforms:repeat-current('attribute-repeat-{position()}')/ancestor-or-self::*/@xpath,
>> '/')))">
>>     <xforms:label
>> ref="xxforms:repeat-current('attribute-repeat-{position()}')/label"/>
>> </xforms:input>
>>
>> I did a little debugging with the following to see what xpath was
>> being evaluated:
>>
>> <xforms:output value="concat('instance(''main-instance'')/document/',
>>    
>> string-join(xxforms:repeat-current('attribute-repeat-{position()}')/ancestor-or-self::*/@xpath,
>> '/'))"/>
>>
>> The output is:
>>
>> instance('main-instance')/document/@authority//mods:mods/mods:titleInfo[1]
>>
>>
>> However, the right result (which came up with version 3.0.1) is:
>>
>> instance('main-instance')/document//mods:mods/mods:titleInfo[1]/@authority
>>
>>
>> I've tested the string-join command in oXygen and get the right
>> result.  I only see it incorrect in OPS 3.5M1.  Any suggestions on
>> this are most welcome.
>>
>> Duane Gran
>>
>>
>> --
>> You receive this message as a subscriber of the
>> [hidden email] mailing list.
>> To unsubscribe: mailto:[hidden email]
>> For general help: mailto:[hidden email]?subject=help
>> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
> ------------------------------------------------------------------------
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

>-----Original Message-----
>From: Erik Bruchez [mailto:[hidden email]] On Behalf Of
>Erik Bruchez
>Sent: 19 September 2006 20:44
>To: [hidden email]
>Subject: Re: [ops-users] 3.5M1 issue with string-join (or
>rather, position)
>
>Duane,
>
>I reproduce this and I am as puzzled as you are! I don't see a
>difference between the XML documents at the output of the
>view, yet the result from xforms:output is different. I also
>reproduced this with smaller versions of your files (attached).
>
>The only thing I know at this point is why the behavior can be
>different in the XForms sandbox: the sandbox does not perform
>XSLT processing at all.
>
>Also, the position() function doesn't have anything to do with
>the issue. If you replace '{position()}' with '123', the issue
>is also visible.
>
>I have entered a bug to track this:
>
>http://forge.objectweb.org/tracker/index.php?func=detail&aid=30
>6168&group_id=168&atid=350207
>
>-Erik
>
>Duane Gran wrote:
>> All,
>>
>> I have an update on this issue, but I'm still perplexed.  The error
>> has to do with the position() function.  I did some testing with the
>> "hello1" and "hello2" tutorial examples and I'm able to
>reproduce this.
>> See the two attached files.
>>
>> * view.html is a replacement for the one in examples/tutorial/hello1
>> * view.xsl is a replacement for the one in examples/tutorial/hello2
>>
>> The files are identical, but the first one displays (correctly):
>>
>>  
>>
>instance('main-instance')/document//mods:mods/mods:titleInfo[1]/@autho
>> rity
>>
>> The second one displays (incorrectly):
>>
>>  
>>
>instance('main-instance')/document/@authority//mods:mods/mods:titleInf
>> o[1]
>>
>> Curiously enough, if I load them into the sandbox they both show the
>> incorrect output.  Any ideas on this are most appreciated.
>>
>> Duane Gran
>>
>>
>> On Sep 7, 2006, at 4:24 PM, Duane Gran wrote:
>>
>>> I upgraded OPS from 3.0.1 and am trying my application in
>3.5M1, but
>>> I'm running into a problem.  I believe the XSL string-join function
>>> isn't returning things in the same order.
>>>
>>> My application makes use of a peer template which governs the order
>>> of elements and various UI aspects for controls.  The view for the
>>> editor is an XSL stylesheet which walks through the template and
>>> reads an "xpath" variable referencing the corresponding elements.  
>>> Are you still with me?  It's crazy, but it works.
>>>
>>> The offending control below fails to display:
>>>
>>> <xforms:input
>>>
>ref="xxforms:evaluate(concat('instance(''main-instance'')/document/',
>>>        
>>>
>string-join(xxforms:repeat-current('attribute-repeat-{position()}')/a
>>> ncestor-or-self::*/@xpath,
>>> '/')))">
>>>     <xforms:label
>>>
>ref="xxforms:repeat-current('attribute-repeat-{position()}')/label"/>
>>> </xforms:input>
>>>
>>> I did a little debugging with the following to see what xpath was
>>> being evaluated:
>>>
>>> <xforms:output
>value="concat('instance(''main-instance'')/document/',
>>>    
>>>
>string-join(xxforms:repeat-current('attribute-repeat-{position()}')/a
>>> ncestor-or-self::*/@xpath,
>>> '/'))"/>
>>>
>>> The output is:
>>>
>>>
>instance('main-instance')/document/@authority//mods:mods/mods:titleIn
>>> fo[1]
>>>
>>>
>>> However, the right result (which came up with version 3.0.1) is:
>>>
>>>
>instance('main-instance')/document//mods:mods/mods:titleInfo[1]/@auth
>>> ority
>>>
>>>
>>> I've tested the string-join command in oXygen and get the right
>>> result.  I only see it incorrect in OPS 3.5M1.  Any suggestions on
>>> this are most welcome.
>>>
>>> Duane Gran
>>>
>>>
>>> --
>>> You receive this message as a subscriber of the
>>> [hidden email] mailing list.
>>> To unsubscribe: mailto:[hidden email]
>>> For general help: mailto:[hidden email]?subject=help
>>> ObjectWeb mailing lists service home page:
>>> http://www.objectweb.org/wws
>>
>>
>>
>----------------------------------------------------------------------
>> --
>>
>>
>> --
>> You receive this message as a subscriber of the
>[hidden email] mailing list.
>> To unsubscribe: mailto:[hidden email]
>> For general help: mailto:[hidden email]?subject=help
>> ObjectWeb mailing lists service home page:
>> http://www.objectweb.org/wws
>
>
>--
>Orbeon - XForms Everywhere:
>http://www.orbeon.com/blog/
>

> Erik,
> It could be the @xsl:version="2.0" at the top of .xsl file, this
> would be a position of 1 is always returned because the AVT would be
> evaluated before xforms uses it? Not sure why this would effect the order it
> is output though, but they certainly is a factor!
>
> Ryan Puddephatt
> Software Engineer
>
> Teleflex Group - IT UK
> 1 Michaelson Square
> Livingston
> West Lothian
> Scotland
> EH54 7DP
>
> e> [hidden email]
> t> +44(0)1506 407 110
> f> +44(0)1506 407 108
>
>  
>
>> -----Original Message-----
>> From: Erik Bruchez [mailto:[hidden email]] On Behalf Of
>> Erik Bruchez
>> Sent: 19 September 2006 20:44
>> To: [hidden email]
>> Subject: Re: [ops-users] 3.5M1 issue with string-join (or
>> rather, position)
>>
>> Duane,
>>
>> I reproduce this and I am as puzzled as you are! I don't see a
>> difference between the XML documents at the output of the
>> view, yet the result from xforms:output is different. I also
>> reproduced this with smaller versions of your files (attached).
>>
>> The only thing I know at this point is why the behavior can be
>> different in the XForms sandbox: the sandbox does not perform
>> XSLT processing at all.
>>
>> Also, the position() function doesn't have anything to do with
>> the issue. If you replace '{position()}' with '123', the issue
>> is also visible.
>>
>> I have entered a bug to track this:
>>
>> http://forge.objectweb.org/tracker/index.php?func=detail&aid=30
>> 6168&group_id=168&atid=350207
>>
>> -Erik
>>
>> Duane Gran wrote:
>>> All,
>>>
>>> I have an update on this issue, but I'm still perplexed.  The error
>>> has to do with the position() function.  I did some testing with the
>>> "hello1" and "hello2" tutorial examples and I'm able to
>> reproduce this.
>>> See the two attached files.
>>>
>>> * view.html is a replacement for the one in examples/tutorial/hello1
>>> * view.xsl is a replacement for the one in examples/tutorial/hello2
>>>
>>> The files are identical, but the first one displays (correctly):
>>>
>>>  
>>>
>> instance('main-instance')/document//mods:mods/mods:titleInfo[1]/@autho
>>> rity
>>>
>>> The second one displays (incorrectly):
>>>
>>>  
>>>
>> instance('main-instance')/document/@authority//mods:mods/mods:titleInf
>>> o[1]
>>>
>>> Curiously enough, if I load them into the sandbox they both show the
>>> incorrect output.  Any ideas on this are most appreciated.
>>>
>>> Duane Gran
>>>
>>>
>>> On Sep 7, 2006, at 4:24 PM, Duane Gran wrote:
>>>
>>>> I upgraded OPS from 3.0.1 and am trying my application in
>> 3.5M1, but
>>>> I'm running into a problem.  I believe the XSL string-join function
>>>> isn't returning things in the same order.
>>>>
>>>> My application makes use of a peer template which governs the order
>>>> of elements and various UI aspects for controls.  The view for the
>>>> editor is an XSL stylesheet which walks through the template and
>>>> reads an "xpath" variable referencing the corresponding elements.  
>>>> Are you still with me?  It's crazy, but it works.
>>>>
>>>> The offending control below fails to display:
>>>>
>>>> <xforms:input
>>>>
>> ref="xxforms:evaluate(concat('instance(''main-instance'')/document/',
>>>>        
>>>>
>> string-join(xxforms:repeat-current('attribute-repeat-{position()}')/a
>>>> ncestor-or-self::*/@xpath,
>>>> '/')))">
>>>>     <xforms:label
>>>>
>> ref="xxforms:repeat-current('attribute-repeat-{position()}')/label"/>
>>>> </xforms:input>
>>>>
>>>> I did a little debugging with the following to see what xpath was
>>>> being evaluated:
>>>>
>>>> <xforms:output
>> value="concat('instance(''main-instance'')/document/',
>>>>    
>>>>
>> string-join(xxforms:repeat-current('attribute-repeat-{position()}')/a
>>>> ncestor-or-self::*/@xpath,
>>>> '/'))"/>
>>>>
>>>> The output is:
>>>>
>>>>
>> instance('main-instance')/document/@authority//mods:mods/mods:titleIn
>>>> fo[1]
>>>>
>>>>
>>>> However, the right result (which came up with version 3.0.1) is:
>>>>
>>>>
>> instance('main-instance')/document//mods:mods/mods:titleInfo[1]/@auth
>>>> ority
>>>>
>>>>
>>>> I've tested the string-join command in oXygen and get the right
>>>> result.  I only see it incorrect in OPS 3.5M1.  Any suggestions on
>>>> this are most welcome.
>>>>
>>>> Duane Gran