Some strengths and weaknesses in Scala's XML capabilities

Today I needed to transform some XML in a fairly minor way; some data
serialized using the XStream library (* task description in footer). I
chose to try it using Scala's XML APIs, my first use of them.

I was surpised by what I discovered tackling the task.

- XML Pattern Matching, which had sounded really cool when I'd read
about it, turned out to be of no use in practice. IMO It should
de-emphasized or even deprecated.

- Much more useful are the \ and \\ operators. This seems to be
because they do what XPath does and are easy to invoke, however they
are less feature-complete and less documented than XPath. Re: level of
docs, compare [eg
http://www.scala-lang.org/docu/files/api/scala/xml/NodeSeq.html#\(String)]
 with [http://www.w3.org/TR/xpath]


1. I suspect a nice integration between Scala XML and javax.xml.xpath
would prove very popular. "Nice" being (a) issuing Java-backed XPath
queries over Scala NodeSeqs is a single method call, (b) where the
query-result is a DOM NodeList, turning it back into a Scala NodeSeq.

An easy way to do this would be with implicits, but this seemingly
requires duplicating the whole NodeSeq into a DOM tree. Still welcome
for non-perf critical use cases, but kinda unsatisfying if it wont
scale out to industrial grade use, as you have to switch tactics
mid-stream (which is against Scala's philosophy).

I just noticed Stephan Koltsov started something more elegant at
[http://code.google.com/p/scala-xml-jaxen/] that appears to adapt the
Jaxen engine to understand Scala XML nodes. javax.XPath seems to offer
similar extension point. Sounds like best long-term option?

Or, make \ & \\ methods work more (or ideally, exactly) like XPath,
but thats alot of work that duplicates working java code.


2. I now feel pages 524-526 of Programming in Scala (XML Pattern
Matching) dont give particularly useful guidance, IMO the sample
problems could be easier solved using only the \ & \\ operators and
for comprehensions.


3. Scala XML Literals allow <a>{ <b/> }</a> (an Elem), and <a/><a/> (a
NodeBuffer), but not <a/>{ <b/> }<a/>. While I (kind of) understand
why, the rules feel rather unintuitive and implementation-driven.
Proposal: Could XML fragment literals, ie any NodeSeq and not just
Elem, be supported by an enclosing delimiter, something similar to """
for strings?


Apologies if these issues were all raked over in detail last week. I
did do a couple of list archive searches before posting.
-Ben



Problem description: Within an XML document, transform fragments of this form:
<vector><default>
  <capacityIncrement>0</capacityIncrement>
  <elementCount>0</elementCount>
  <elementData id="1291">
    <null/>
  </elementData>
</default></vector>

...into this:
<size>0</size>
<elementData id="1291">
    <null/>
</elementData>