Re: [basex-talk] sequences after the path operator
Hi Christian --
*> The document order can only be restored if the result of an
expression is a sequence of nodes.*
Thank you! That does help, in as much as I was thinking that the order
came from the left side, not the right side. I feel much less confused now.
(I used an if in the original of the real code from which the example was
derived and my brain kept insisting it was inaesthetic, presumably from too
much xsl:apply-templates.)
Much appreciated!
Graydon
On Fri, Jul 7, 2023 at 3:17 AM Christian Grün
wrote:
> Hi Graydon,
>
> The document order can only be restored if the result of an expression
> is a sequence of nodes. In the given case, …
>
> analyze-string($test,'\p{Lu}')/(
> fn:match/concat('[',.,']'),
> fn:non-match/string()
> )
>
> …two string sequences are generated (for matches and non-matches)
> which have no inherent relationship to the original nodes:
>
> • matches: ”[A]”, ”[O]”, ”[L]”
> • non-matches: ”nd”, “ ”, “ord the …”
>
> You have already presented a version that works. Here’s another
> one-liner that creates a new result for each (non-)match element in
> the original order:
>
> let $syntax2 := string-join(analyze-string($test,'\p{Lu}')/* !
> (if(self::fn:match) then '[' || . || ']' else .))
>
> Hope his helps,
> Christian
>
>
> On Fri, Jul 7, 2023 at 3:32 AM Graydon Saunders
> wrote:
> >
> > Hello --
> >
> > Using BaseX 10.6, the test query
> >
> > let $test as xs:string := "And O Lord the pride of man, broken in the
> dust again"
> >
> > let $syntax1 as xs:string :=
> analyze-string($test,'\p{Lu}')/(fn:match/concat('[',.,']'),fn:non-match/string())
> => string-join('')
> >
> > let $syntax2 as xs:string :=
> analyze-string($test,'\p{Lu}')/*/(self::fn:match/concat('[',.,']'),self::fn:non-match/string())
> => string-join('')
> >
> > return ($syntax1,$syntax2)
> >
> > produces
> >
> > [A][O][L]nd ord the pride of man, broken in the dust again
> > [A]nd [O] [L]ord the pride of man, broken in the dust again
> >
> > I'm surprised by this, because I expected document order to apply to the
> result of analyze-string and for syntax1 to work in the sense of having the
> results emerging in the same order as the input.
> >
> > Have I miscomprehended something? Anyone care to have a go at
> explaining why syntax1 doesn't maintain the order of the input? (I'm
> possibly mistakenly confident that I understand why syntax2 does.)
> >
> > Thanks!
> > Graydon
> >
> > --
> > Graydon Saunders | graydon...@fastmail.com
> > Þæs oferéode, ðisses swá mæg.
> > -- Deor ("That passed, so may this.")
>
Re: [basex-talk] Apparent bug when setting @xml:base on element with @base
Hi Eliot,
Thanks for the observation, a bug fix is available [1,2].
Best,
Christian
[1] https://files.basex.org/releases/latest/
[2] https://github.com/BaseXdb/basex/issues/2227
On Fri, Jul 7, 2023 at 12:48 AM Eliot Kimber
wrote:
>
> This XQuery demonstrates the problem:
>
> (::)
> let $xmlBaseAtt as attribute() := attribute {'xml:base'}{'/foo/bar.xml'}
>
> let $transformed1 as element() :=
>
> try {
>
> $doc1 transform with { insert node $xmlBaseAtt into .}
>
> } catch * {
>
>
>
> }
>
>
>
> let $transformed2 as element() :=
>
> try {
>
> $doc2 transform with { insert node $xmlBaseAtt into .}
>
> } catch * {
>
>
>
> }
>
>
>
> return (
>
> ``[No @base attribute:]``
>
> ,$transformed1
>
> ,``[Has @base attribute:]``
>
> ,$transformed2
>
> ,()
>
> )
>
> (::)
>
> The results I get with 10.6 are:
>
>
>
> No @base attribute:
>
>
>
> Has @base attribute:
>
> object="doc2"/>
>
>
>
> It looks like the transform processor is matching @xml:base to @base even
> though they are different attributes.
>
>
>
> Is this a bug or is there a different way I should be specifying the
> @xml:base attribute?
>
>
>
> This is an issue because @base is a DITA-defined attribute that occurs on
> elements on which I need to set @xml:base (which is how I found the problem).
>
>
>
> Cheers,
>
>
>
> Eliot
>
>
>
>
>
>
>
>
>
> _
>
> Eliot Kimber
>
> Sr Staff Content Engineer
>
> O: 512 554 9368
>
> M: 512 554 9368
>
> servicenow.com
>
> LinkedIn | Twitter | YouTube | Facebook
Re: [basex-talk] sequences after the path operator
Hi Graydon,
The document order can only be restored if the result of an expression
is a sequence of nodes. In the given case, …
analyze-string($test,'\p{Lu}')/(
fn:match/concat('[',.,']'),
fn:non-match/string()
)
…two string sequences are generated (for matches and non-matches)
which have no inherent relationship to the original nodes:
• matches: ”[A]”, ”[O]”, ”[L]”
• non-matches: ”nd”, “ ”, “ord the …”
You have already presented a version that works. Here’s another
one-liner that creates a new result for each (non-)match element in
the original order:
let $syntax2 := string-join(analyze-string($test,'\p{Lu}')/* !
(if(self::fn:match) then '[' || . || ']' else .))
Hope his helps,
Christian
On Fri, Jul 7, 2023 at 3:32 AM Graydon Saunders wrote:
>
> Hello --
>
> Using BaseX 10.6, the test query
>
> let $test as xs:string := "And O Lord the pride of man, broken in the dust
> again"
>
> let $syntax1 as xs:string :=
> analyze-string($test,'\p{Lu}')/(fn:match/concat('[',.,']'),fn:non-match/string())
> => string-join('')
>
> let $syntax2 as xs:string :=
> analyze-string($test,'\p{Lu}')/*/(self::fn:match/concat('[',.,']'),self::fn:non-match/string())
> => string-join('')
>
> return ($syntax1,$syntax2)
>
> produces
>
> [A][O][L]nd ord the pride of man, broken in the dust again
> [A]nd [O] [L]ord the pride of man, broken in the dust again
>
> I'm surprised by this, because I expected document order to apply to the
> result of analyze-string and for syntax1 to work in the sense of having the
> results emerging in the same order as the input.
>
> Have I miscomprehended something? Anyone care to have a go at explaining why
> syntax1 doesn't maintain the order of the input? (I'm possibly mistakenly
> confident that I understand why syntax2 does.)
>
> Thanks!
> Graydon
>
> --
> Graydon Saunders | graydon...@fastmail.com
> Þæs oferéode, ðisses swá mæg.
> -- Deor ("That passed, so may this.")
