Ok. Try the below. I have not tried all your examples below - only the first. Looks quite verbose, unfortunately.
You *could* remove the xmlns namespace to begin with, process and then re-insert. In fact that's one option I may explore to get XMLTask to work more nicely with the namespace grief that people often encounter. Brian <xmltask source="sample.xml"> <call path="/*[local-name()='root']/*[local-name()='entry']" target="process-node"> <param name="key" path="*[local-name()='key']/text()"/> <param name="value" path="*[local-name()='value']/text()"/> </call> </xmltask> Brian On Tue, June 3, 2008 09:11, MichaŠTkacz wrote: > Sorry for repeating myself, but it would be kind of useful for me to > know the solution ;) > Does anyone know it? > > My previous post was sent in HTML and was not very readable on the > sourceforge page. Sorry about that. See it for attachments. Here's the > message itself, this time in plain text. > > Thanks in advance. > > Michal > > MichaŠTkacz wrote: >> Thanks for the reply Brian. I've attached sample xml file as well as a >> bunch of scripts that illustrate the problem. "b" versions differ in >> that they use nested <actions> instead of separate target. >> >> The main difference between your xml file and mine is that in mine >> namespace is set using xmls attribute instead of xmlns:prefix attribute. >> >> Michal >> >> Brian Agnew wrote: >>> Michael, >>> >>> Thx for the below. Can you provide a simplified input XML document for >>> the >>> below so we both know what we're looking at wrt. inputs ? >>> >>> Note the following appears better: >>> <target name="abc"> >>> <xmltask source="a.xml" dest="b.xml"> >>> <call path="/yh:some/yh:path" target="process-node"> >>> <param name="value" path="yh:subpath/text()"/> >>> </call> >>> </xmltask> >>> </target> >>> <target name="process-node"> >>> <echo>Process node called with ${value}</echo> >>> </target> >>> >>> where the input document is: >>> >>> <yh:some xmlns:yh="http://www.yahoo.com" xmlns="http://junk.com"> >>> <yh:path> >>> <yh:subpath>1</yh:subpath> >>> </yh:path> >>> <yh:path> >>> <yh:subpath>2</yh:subpath> >>> </yh:path> >>> </yh:some> >>> >>> Second question: when you look to modify the XML within the target of a >>> <call>, how are you passing it ? As a buffer and into XMLTask again ? >>> Or >>> as a property ? >>> >>> Brian >>> >>> On Wed, May 28, 2008 17:33, Micha³ Tkacz wrote: >>> >>>> Hello Brian, >>>> >>>> I have following namespace-related problem, which I'm unable to solve. >>>> Maybe you can help me, otherwise it's something to consider for the >>>> next >>>> version of xmltask. >>>> >>>> I have an xml document where each node comes from the same namespace. >>>> I'm trying to loop over all nodes matching an xpath using <call>. For >>>> each node I need to access certain subnodes. >>>> >>>> >>>> Script 1: >>>> >>>> <call path="/:some/:path" target="process-node"> >>>> <param name="value" path=":sub-node/text()"/> >>>> </call> >>>> >>>> throws >>>> >>>> javax.xml.transform.TransformerException: A location path was >>>> expected, >>>> but the following token was encountered: :sub-node >>>> >>>> >>>> Script 2: >>>> >>>> <call path="/:some/:path" target="process-node"> >>>> <param name="value" path="/:sub-node/text()"/> >>>> </call> >>>> >>>> (slash added) fails to match sub-node element. >>>> >>>> >>>> Script 3: >>>> >>>> <call path="/:some/:path" target="process-node" buffer="node"/> >>>> >>>> [...] >>>> >>>> <target name="process-node"> >>>> <xmltask sourcebuffer="node"> >>>> <copy path=":sub-node/text()" property="value"/> >>>> </xmltask> >>>> </target> >>>> >>>> throws >>>> >>>> javax.xml.transform.TransformerException: A location path was >>>> expected, >>>> but the following token was encountered: :sub-node >>>> >>>> >>>> Script 4: >>>> >>>> <call path="/:some/:path" target="process-node" buffer="node"/> >>>> >>>> [...] >>>> >>>> <target name="process-node"> >>>> <xmltask sourcebuffer="node"> >>>> <copy path="*/*:sub-node/text()" property="value"/> >>>> </xmltask> >>>> </target> >>>> >>>> (slash added) throws >>>> >>>> com.sun.org.apache.xpath.internal.domapi.XPathStylesheetDOM3Exception: >>>> Prefix must resolve to a namespace: >>>> >>>> >>>> Using nested actions instead of target doesn't change anything. Using >>>> "sub-node/text()" without a colon fails to match sub-node element for >>>> obvious reasons. >>>> >>>> >>>> Is there a way to achieve what I need with xmltask 1.15.1? >>>> >>>> Another idea: <call> seems to make a copy of a matching node which >>>> makes >>>> it impossible to modify it so that the changes are reflected in >>>> original >>>> document. How about adding additional parameter, saying whether a copy >>>> should be made or not? >>>> >>>> Help will be much appreciated. >>>> >>>> Michal >>>> >>>> Brian Agnew wrote: >>>> >>>>> Hi - >>>>> >>>>> A number of issues have come up recently regarding XMLTask and >>>>> namespaces. >>>>> I think these can be reduced to 2 fundamental issues: >>>>> >>>>> 1) XPaths for namespace-enabled documents are confusing. Or rather, >>>>> people >>>>> are not aware of how these should work. >>>>> >>>>> 2) Inserting non-namespaced documents/fragments into >>>>> namespace-enabled >>>>> documents doesn't quite work as expected (resulting in empty xmlns >>>>> attributes and the like) >>>>> >>>>> (I believe that XMLTask is doing what it's asked to correctly - >>>>> however >>>>> XMLTask exists to make people's lives easier and so we should be >>>>> asking >>>>> it >>>>> to do more) >>>>> >>>>> I aim to fix both the above in the next release (no ETA, since I have >>>>> no >>>>> spec!). If there are other namespace issues that you believe are not >>>>> covered in the above and that are causing you grief, please let me >>>>> know. >>>>> The development of XMLTask is driven solely by customer requests now! >>>>> >>>>> Brian >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------- >>>> This SF.net email is sponsored by: Microsoft >>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ >>>> Xmltask-users mailing list >>>> Xmltask-users@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/xmltask-users >>>> >>>> >>> >>> >>> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Xmltask-users mailing list >> Xmltask-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/xmltask-users > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Xmltask-users mailing list > Xmltask-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xmltask-users > -- Brian Agnew http://www.oopsconsultancy.com OOPS Consultancy Ltd Tel: +44 (0)7720 397526 Fax: +44 (0)20 8682 0012 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Xmltask-users mailing list Xmltask-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xmltask-users