« Return to Thread: Some strengths and weaknesses in Scala's XML capabilities

Re: Some strengths and weaknesses in Scala's XML capabilities

by Arrgh :: Rate this Message:

Reply to Author | View in Thread

Ben Hutchison wrote:

> - 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.
>  
There's been some talk of enhancing Scala's XML pattern matching recently; at the moment I'm not aware of any concrete, fully fleshed-out proposal though.  http://thread.gmane.org/gmane.comp.lang.scala.xml/92/focus=103 is probably the most recent discussion of any substance on the subject.

> - 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).
>  
It would certainly be very nice to have some kind of native XPath support.  It probably can't look much like the idiomatic XPath syntax, but I suspect it would be much better to try to leverage for comprehensions anyway.   Also note that due to scala.xml's approach to immutability, nodes don't know their parent, so some types of expression will be significantly harder to implement than others.

And while I do think it would be quite useful to have round trip
org.w3c.dom conversion routines, I'm not sure how politically correct it
would be to couple against the Java DOM APIs in the Scala standard
library. I'd suggest filing an enhancement request anyway. :)

It would probably be nice to have connections between scala.xml and
existing XPath APIs, but the same concern about their suitability in the
Scala standard library applies.  Maybe something like sbaz or scalax
(unfortunately neither seems particularly lively at the moment) is the
natural home for them?
> Or, make \ & \\ methods work more (or ideally, exactly) like XPath,
> but thats alot of work that duplicates working java code.
>  
I think at this point we need some very concrete suggestions to
stimulate further suggestion.  Ordinarily I'm very generous with ideas
about how Somebody Really Oughta do things but I'm a bit pressed for
time these days. :/
> 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?
>  
If you scroll down a bit at
http://burak.emir.googlepages.com/scalaxbook.docbk.html#id2893345 you'll
see <xml:group/> for precisely this purpose. :)

Thanks for your feedback!

-0xe1a

 « Return to Thread: Some strengths and weaknesses in Scala's XML capabilities