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

>
> 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  {  }  (an Elem), and    (a NodeBuffer), but
>> not  {  } . 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
>
>