[XQuery Talk Mailing List Archive Home] [By Date] [By Thread] [By Subject] [By Author] [Recent Entries] [Reply To This Message]

Re: replacing a node in in-memory XML

Thomas Lord lord at emf.net
Tue Nov 6 16:30:14 PST 2007


  Re: replacing a node in in-memory XML
Another follow-up for Wolfgang's good tip:

Think carefully about how many copies of a given
element your input might have, and how many copies
of a given output you want it to have.

Consider these three variations (for example):

    element {QName ($n)}
    {
      $n/@*,
      for $c in $n/node()
      typeswitch ($c)
      case element foo return <my-foo-replacement/>
      default return $c
    }

and

    element {QName ($n)}
    {
      $n/@*,
      for $c in $n/node()
      typeswitch ($c)
      case element foo return ()
      default return $c,
      <my-foo-replacement/>
    }
and

    element {QName ($n)}
    {
      $n/@*,
      for $c in $n/node()
      typeswitch ($c)
      case element foo return ()
      default return $c,
      if ($n/foo) then <my-foo-replacement/> else ()
    }

You can score a lot of good "robustness karma points" if
you make the right choices among variations like those.
(And, you can make distinctions like that in XSLT just fine
but I'm not sure that code comes out clearer than
the above examples!)

Also, don't forget to copy attributes (as illustrated)
when appropriate!  (And, you can do the same trick to
edit attributes, btw.)

-t


Hans-Juergen Rennau wrote:
> Hello Wolfgang,
>
> let me add a remark about the situation when the nodes to be modified cannot be identified by type *ALONE*. For example, the document might contain many community groups, and the services element is to be replaced only in the groups (2, 31, 32, 40). In such situations, I suggest to combine the "typeswitch recursion pattern" with a "node marking pattern": a) before starting the recursion, "mark" the modification targets by collecting them in a variable, b) within the relevant typeswitch branch use a node identity-based if/else. This approach scales rather well when things get more complicated (several element types are to be partially and heterogeneously modified).
>
> a) 
> declare variable $targetNodes_services := 
>    ($doc//communitygroup)[position() = (2, 31, 32, 40)]/group/services
>
> b)
> typeswitch ($node)
>    case $elem as element(services) return
>       if ($elem intersect $targetNodes_services) then <services>...</services>
>       else
>
> 		         element {node-name($elem)} {$elem/@*, $elem/node()/local:replace(.)}
>     ...
>
> The approach helped me when I had to modify WordML documents, highly repetitive as they are in terms of element names!
>
> With kind regards,
> Hans-Juergen
>
>
>
>
>
>        __________________________________ Ihr erstes Fernweh? Wo gibt es den schönsten Strand? www.yahoo.de/clever
>
> _______________________________________________
> http://x-query.com/mailman/listinfo/talk
> http://x-query.com/mailman/listinfo/talk
>



Purchase Stylus Studio Online Today!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2007 All Rights Reserved.