nk4um

The updated saxon module is in now in the apposite repository.

Notable changes:

* updated included version of the saxon library 9.2HE
* added an xpath2 accessor
* added an XdmNode represenation (which is exposed and can be used by other modules)

Thanks to Menzo and Peter for their help with this!

Cheers,

Chris

Good plan. I''ll try and finish it off and check-in this evening for review - don''t be surprised if it ends up being tomorrow eve!

Chris

This sounds good.  Presumably the necessary libs are already in the xml-saxon package?

Chris/Menzo why don''t we put it in that module and commit the development to the project SVN svn://svn.netkernel.org/svn/xml-saxon/  (you''re both committers).

P.

It''s on its way :-)

Menzo

Hi Menzo,

That looks like it could be quite useful. If you could send the source code, that might give me some useful direction!

Chris

Hi, All,

In NK3 the xpath2eval accessor supported the namespace parameter (see http://docs.1060.org/docs/3.3.0/book/developerreference/doc_ura_xpath2eval.html).

In my own set of NK3 accessors I also have a variant of xpath2eval which is also able to return (DPML canonical) values. If it still makes sense in the NK4 context I can send the source code.

If used as a xpath2eval replacement this accessor returns effective boolean values as specified by the XPath 2 standard (see http://www.w3.org/TR/2007/REC-xpath20-20070123/#id-ebv).

Greetings,

Menzo

Just tried another XPath1 experiment.

It seems you can do:

/*[namespace-uri()=''test''][local-name()=''test'']/text()

but it is a lot harder to maintain than the XPath2 version!

Chris

ugh! Ignore the fact that I signed that off half-way through the message! Not enough coffee, I imagine!

Would that also be namespace-aware?

The implementation based on XPath1 won''t be, but I''ve started work on one based around XPath2 (using saxon9), which is.
Consider the following example:

<test xmlns="test">hello</test>

With XPath1:

/test/text()

does not work, but it does with XPath2. This is because XPath1 considers everything without a prefix as being in the null namespace, whereas XPath2 is more flexible and uses the current context for the default namespace. The context for the implementation I''m considering is the root element. This will work for most situations, but not if the desired namespace is declared on an element further down the tree, consider:

<test xmlns="test">   <test2:test2 xmlns:test2="test2">hello</test2:test2> </test>

Hope that helps,

Chris

You can''t do:

/test/test2:test2/text()

but you can match any element with the local-name "test2" in any namespace:

/test/*:test2/text()

or, if you want to match on that namespce and local-name:

/test/*:test2[namespace-uri()=''test2'']/text()

That would indeed be great. Thanks.
Would that also be namespace-aware?

Cheers,
Carlos

Hi Peter,

Just checked.

No extra libraries! It uses XDA, so quite similar to Java example you gave.

Cheers,

Chris

Hi Chris,

That sounds like just the ticket!  Does it require any additional Java library other than what we ship in xml:core already?  If not then it''d be easy to just add in to xml:core.

P.

Hi,

I have an xpath module which supplies the functionality that you are looking for (and is what I was discussing in the other thread). It hasn''t been documented yet, but I can do that this evening.

you''d be able to do the following (example using DPML):

<requestassignment="response">   <identifier>active:xpath</identifier>   <argumentname="operand">http://musicbrainz.org/ws/1/artist/?type=xml&amp;limit=1&amp;name=nirvana</argument>   <argumentname="xpath">     <literaltype="string">//artist[1]/@id</literal>   </argument>   <argumentname="type">     <literaltype="string">string</literal>   </argument> </request>

Peter - is it worth putting this module in the multiverse? or would the accessor make more sense in urn:org:netkernel:xml:core?

Cheers,

Chris

Yes it does. Thanks
I take it then that there is no direct way to do this through some simple active:xpointer (as indicated in the post above) or something along these lines, right?

Cheers,
Carlos

Here''s one solution off the top of my head solution (thrown together in Groovy - but you easily see how to do the Java)...

import org.netkernel.xml.xda.*; import org.w3c.dom.*; xml=context.source("http://musicbrainz.org/ws/1/artist/?type=xml&limit=1&name=nirvana", Document.class); xda=new DOMXDA(xml); xda.removeNS("/*", "");   //Get rid of the default namespace so that XPath works! attr=xda.getText("//artist[1]/@id", true); resp=context.createResponseFrom(attr); resp.setMimeType("text/plain");

(How I wish default namespaces were banned - they completely screw up XPath)

You could also do this with E4X which offers native XML tools if you used Javascript - see active:javascript for details (after installing the lang-javascript package).

Interestingly you highlight the need for another type of XML DSL - a declarative language that can do extraction to POJOs pieces of the XML tree.  The tool coverage with NK tends be powerful for XML->XML transformation but XML->POJO is currently done by dropping to a scripting language (or Java).

Hope this helps.

Hi,
I''ve been trying for a while to get a particular attribute from a piece of XML with no luck.
I initially thought this should be directly doable through something like what is indicated at http://1060.org/forum/topic/564

I checked for other possibilities and ended up coding some Java for it. Still, if we want to stick to NK libraries, the only thing I found that could help was XMLReadable and still I''m not able to get it to work since (I believe this is the issue) the xml uses a default namespace.

I''m certainly sure that I''m missing something and there should be very simple means for doing it.  Iwould appreciate any help in getting both the simple and Java-based version to work (the latter without using external libs direclty indeed).

The XML I want to manipulate can be obtained here:
http://musicbrainz.org/ws/1/artist/?type=xml&limit=1&name=nirvana

And the attribute I want to get is the ''id'' for the artist.

Cheers,
Carlos