Parallel data traversal

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Vojta

    Parallel data traversal

    Hi,

    I have some xml data looking like this
    <root>
    <items1>
    <i1>..</i1>
    <i1>..</i1>
    </items1>
    <items2>
    <i2>..</i2>
    <i2>..</i2>
    </items2>
    </root>

    If my context node is the k-th node in items1 is to possible to create
    XPath that finds a k-th node in items2? Something like "../../
    items2[position() = position(.)]" - which does not work because "." is
    bound to some "i2" node inside the square brackets.

    Some motivation: we use a "repeater" component that traverses child
    nodes of one node. The current node in the repeater is the context
    node. The user then uses xpaths relative to the current node to get
    the data. And I need some hack to be able to reference nodes at the
    same position but inside a different node.

    Obviously the most natural solution is to do some data preprocessing
    to "zip" items1 and items2 together or modify our repeater to be able
    to have multiple context nodes. But isn't there any pure xpath way to
    do this?

    Thanks

  • Pavel Lepin

    #2
    Re: Parallel data traversal


    Vojta <dr.fie@seznam. czwrote in
    <1189410536.254 273.316180@r34g 2000hsd.googleg roups.com>:
    <root>
    <items1>
    <i1>..</i1>
    <i1>..</i1>
    </items1>
    <items2>
    <i2>..</i2>
    <i2>..</i2>
    </items2>
    </root>
    >
    If my context node is the k-th node in items1 is to
    possible to create XPath that finds a k-th node in items2?
    Something like "../../ items2[position() = position(.)]" -
    which does not work because "." is bound to some "i2" node
    inside the square brackets.
    >
    Obviously the most natural solution is to do some data
    preprocessing to "zip" items1 and items2 together or
    modify our repeater to be able to have multiple context
    nodes.
    That is the most natural solution indeed. And it's a trivial
    transformation, too.
    But isn't there any pure xpath way to do this?
    Short answer: no, there isn't any pure XPath way of doing
    that. You need either variables (that is, you have to
    generate the XPath expression on the fly, it cannot be
    static), or XPath extensions (XSLT defines the current()
    function which returns the current node; but the notion of
    the current node is defined by XSLT spec as well, and isn't
    by itself meaningful outside of XSLT context).

    --
    This chickenus crossed the roadus while yodelingus.

    Comment

    • David Carlisle

      #3
      Re: Parallel data traversal

      Vojta wrote:
      Hi,
      >
      I have some xml data looking like this
      <root>
      <items1>
      <i1>..</i1>
      <i1>..</i1>
      </items1>
      <items2>
      <i2>..</i2>
      <i2>..</i2>
      </items2>
      </root>
      >
      If my context node is the k-th node in items1 is to possible to create
      XPath that finds a k-th node in items2? Something like "../../
      items2[position() = position(.)]" - which does not work because "." is
      bound to some "i2" node inside the square brackets.
      >
      Some motivation: we use a "repeater" component that traverses child
      nodes of one node. The current node in the repeater is the context
      node. The user then uses xpaths relative to the current node to get
      the data. And I need some hack to be able to reference nodes at the
      same position but inside a different node.
      >
      Obviously the most natural solution is to do some data preprocessing
      to "zip" items1 and items2 together or modify our repeater to be able
      to have multiple context nodes. But isn't there any pure xpath way to
      do this?
      >
      Thanks
      >
      not pure xpath1 you need xslt1 or a similar host language that can bind
      xpath variables.

      however in xpath2 you can express this, for example

      for $p in 1+count(precedi ng-sibling::i1) return
      .../preceding-sibling::items2/i2[$p]

      David
      --

      Comment

      Working...