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

Reply via email to