Arrgh wrote:
>
> 2) Proposed enhancements

1. XPath. Not as a replacement for the existing query mechanism, which is
good and has its place, but there are many features of XPath that it doesn't
support.

val isbns = xml \ "library/books/book[author.surname='Atwood']/@idbn" map
{ _.text }

I'm told that there are features of XPath that the Scala XML model cannot
support, since they aren't compatible with the functional way of storing the
data (ie no parents). But I suspect most features can be supported with a
little trickery, and the few that cannot be supported are rare edge cases. I
trust that a solution can be reached which satisfies 98% of cases. But even
a partial, simplified subset of XPath would be immensely useful.

Some will inevitably reply that I should be using a more scala-like method
to do the above filtering. There are several good answers to that, but the
main is that XPath is a standard. That means people already know it, they
already have large amounts of work that uses it, and the lack of it makes
Scala much less attractive as an XML-processing platform.

2. Mutable XML. I'm not sure exactly how to achieve this, but there needs to
be some way of making a modification to an existing XML tree - adding,
replacing or removing nodes at arbitrary points within it. The recommended
way of doing this at present is to recreate the entire tree, but that
presupposes that I know the full structure of the tree in advance.

There are two ways I can see to achieve this. The more functional way would
be to recreate the entire tree at each stage, but incorporate some change.
I've no idea what the syntax for this would looks like, so I'm going to make
something up:

val xml2 = xml set {
_ \ "library" \ "books" +=

The Blind Assassin

MargaretAtwood

}

The less functional but probably more practical way is to temporarily
convert the xml into a mutable form that would allow you to change a number
of things, which can then be converted back to the non-mutable form.

val m = xml.toMutable
m \ "library" \ "books" +=

The Blind Assassin

MargaretAtwood

m query "library/books[author.surname='Atwood']" foreach { _ +=
}
val xml2 = m.toImmutable

The mutable xml would adhere to the same interface as the existing immutable
version. I imagine the toMutable step would involve the minimum of
conversion - at first only the root node would be replaced with a mutable
equivalent. Child nodes could be swapped for mutable versions as they are
returned from queries. When the modifications are done, the toImmutable
would only need to convert those that have been affected by a change.

Alex,

You might also want to put up a link on the scala mailing lists page to join the scala-xml list.

Best wishes,

--greg

On Fri, Jan 30, 2009 at 3:34 PM, Alex Cruise <alex@cluonflux.com> wrote:

Hi folks!

I'm Alex Cruise (obviously!) I'm a software architect at http://www.layer7tech.com/ (located in Vancouver, Canada) and have been hanging around the Scala community for about a year and a half.  I have recently volunteered to serve as a coordinator for the Scala XML team.  At this time, the XML team (apart from EPFL people, of course) consists of myself, Michael Fogus, Normen Müller and (I think) David Pollak, but contributions--including bug reports, patches, complaints, feature requests and existential angst--are of course welcome from everyone.

On behalf of said team, I would like to invite everyone who is interested in Scala's XML support to join the new scala-xml list!  (This post cc'd to scala and liftweb--the latter because the Lift project is easily one of the heaviest users of scala.xml, and I'm certain that members of that community will enthusiastically join in the discussion in short order. :)  If you'd like to watch the sausage being made, or even turn the crank a bit yourself, please subscribe to scala-xml by sending an empty email to scala-xml-subscribe@listes.epfl.ch .

Here's some background info for anyone who is unfamiliar with Scala's XML support:  The Scala compiler supports XML literals in Scala source files, with very few additional restrictions on their syntax.  XML literals are translated into a tree built from instances of several classes in the scala.xml package (http://www.scala-lang.org/docu/files/api/scala/xml$package.html), and may contain nested Scala expressions (each of which can also incorporate sub-nested XML literals, etc...) whose results are interpolated into the XML.

The scala.xml.Node class and its descendants form a comparatively lightweight, immutable, DOM-like representation of XML that can be used in pattern matching and provide simple, XPath-like node selection queries. The package also contains a few parsers and other assorted tools.

IMO we owe a debt of gratitude to Burak Emir, the primary developer of scala.xml.  I believe he has laid a solid foundation that will serve us well.  Burak also wrote http://burak.emir.googlepages.com/scalaxbook.docbk.html which gives insight into the rationale behind the design and implementation of the library.

Now, let's kick off the list with a small agenda:

1) Bug triage

Rather than list the (~18) known bugs here, I'll supply an URL (http://lampsvn.epfl.decenturl.com/scala-xml-bugs), and anyone who feels like their favourite bug merits further discussion should fire up a new topic on scala-xml and we'll start hashing it out.  If nobody pipes up I'll start posting individual emails regarding each bug with a few of my own comments in a few days.

2) Proposed enhancements

I'm sure many of us have a wish list of things we would like to see changed in Scala's XML support--please feel free to join in and tell us all about them.

Thanks for your time,

-0xe1a

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com

Alex,

This is probably way out of scope, but since someone brought up XPath, i couldn't resist... LINQ-like support for XQuery?

Best wishes,

--greg

On Fri, Jan 30, 2009 at 3:34 PM, Alex Cruise <alex@cluonflux.com> wrote:

Hi folks!

I'm Alex Cruise (obviously!) I'm a software architect at http://www.layer7tech.com/ (located in Vancouver, Canada) and have been hanging around the Scala community for about a year and a half.  I have recently volunteered to serve as a coordinator for the Scala XML team.  At this time, the XML team (apart from EPFL people, of course) consists of myself, Michael Fogus, Normen Müller and (I think) David Pollak, but contributions--including bug reports, patches, complaints, feature requests and existential angst--are of course welcome from everyone.

On behalf of said team, I would like to invite everyone who is interested in Scala's XML support to join the new scala-xml list!  (This post cc'd to scala and liftweb--the latter because the Lift project is easily one of the heaviest users of scala.xml, and I'm certain that members of that community will enthusiastically join in the discussion in short order. :)  If you'd like to watch the sausage being made, or even turn the crank a bit yourself, please subscribe to scala-xml by sending an empty email to scala-xml-subscribe@listes.epfl.ch .

Here's some background info for anyone who is unfamiliar with Scala's XML support:  The Scala compiler supports XML literals in Scala source files, with very few additional restrictions on their syntax.  XML literals are translated into a tree built from instances of several classes in the scala.xml package (http://www.scala-lang.org/docu/files/api/scala/xml$package.html), and may contain nested Scala expressions (each of which can also incorporate sub-nested XML literals, etc...) whose results are interpolated into the XML.

The scala.xml.Node class and its descendants form a comparatively lightweight, immutable, DOM-like representation of XML that can be used in pattern matching and provide simple, XPath-like node selection queries. The package also contains a few parsers and other assorted tools.

IMO we owe a debt of gratitude to Burak Emir, the primary developer of scala.xml.  I believe he has laid a solid foundation that will serve us well.  Burak also wrote http://burak.emir.googlepages.com/scalaxbook.docbk.html which gives insight into the rationale behind the design and implementation of the library.

Now, let's kick off the list with a small agenda:

1) Bug triage

Rather than list the (~18) known bugs here, I'll supply an URL (http://lampsvn.epfl.decenturl.com/scala-xml-bugs), and anyone who feels like their favourite bug merits further discussion should fire up a new topic on scala-xml and we'll start hashing it out.  If nobody pipes up I'll start posting individual emails regarding each bug with a few of my own comments in a few days.

2) Proposed enhancements

I'm sure many of us have a wish list of things we would like to see changed in Scala's XML support--please feel free to join in and tell us all about them.

Thanks for your time,

-0xe1a

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com

Isn't Scala's XML already linq-like support for XQuery?

An XQuery example from wikipedia:

<html><head/><body>
{
  for $act in doc("hamlet.xml")//ACT
  let $speakers := distinct-values($act//SPEAKER)

  return
    <div>
      <h1>{ string($act/TITLE) }</h1>
      <ul>
      {
        for $speaker in $speakers
        return <li>{ $speaker }</li>
      }
      </ul>

    </div>
}
</body></html>

A port to Scala:

<html><head/><body>
{
  for { act <- doc("hamlet.xml") \\ "ACT"
        speakers = distinctValues(act \\ "SPEAKER") }

      yield
        <div>
          <h1>{ act \ "TITLE" }</h1>
          <ul>
          {
            for (speaker <- speakers)
              yield <li>{ speaker }</li>

          }
          </ul>
        </div>
}
</body></html>

2009/1/31 Meredith Gregory <lgreg.meredith@gmail.com>

Alex,

This is probably way out of scope, but since someone brought up XPath, i couldn't resist... LINQ-like support for XQuery?

Best wishes,

--greg

On Fri, Jan 30, 2009 at 3:34 PM, Alex Cruise <alex@cluonflux.com> wrote:

Hi folks!

I'm Alex Cruise (obviously!) I'm a software architect at http://www.layer7tech.com/ (located in Vancouver, Canada) and have been hanging around the Scala community for about a year and a half.  I have recently volunteered to serve as a coordinator for the Scala XML team.  At this time, the XML team (apart from EPFL people, of course) consists of myself, Michael Fogus, Normen Müller and (I think) David Pollak, but contributions--including bug reports, patches, complaints, feature requests and existential angst--are of course welcome from everyone.

On behalf of said team, I would like to invite everyone who is interested in Scala's XML support to join the new scala-xml list!  (This post cc'd to scala and liftweb--the latter because the Lift project is easily one of the heaviest users of scala.xml, and I'm certain that members of that community will enthusiastically join in the discussion in short order. :)  If you'd like to watch the sausage being made, or even turn the crank a bit yourself, please subscribe to scala-xml by sending an empty email to scala-xml-subscribe@listes.epfl.ch .

Here's some background info for anyone who is unfamiliar with Scala's XML support:  The Scala compiler supports XML literals in Scala source files, with very few additional restrictions on their syntax.  XML literals are translated into a tree built from instances of several classes in the scala.xml package (http://www.scala-lang.org/docu/files/api/scala/xml$package.html), and may contain nested Scala expressions (each of which can also incorporate sub-nested XML literals, etc...) whose results are interpolated into the XML.

The scala.xml.Node class and its descendants form a comparatively lightweight, immutable, DOM-like representation of XML that can be used in pattern matching and provide simple, XPath-like node selection queries. The package also contains a few parsers and other assorted tools.

IMO we owe a debt of gratitude to Burak Emir, the primary developer of scala.xml.  I believe he has laid a solid foundation that will serve us well.  Burak also wrote http://burak.emir.googlepages.com/scalaxbook.docbk.html which gives insight into the rationale behind the design and implementation of the library.

Now, let's kick off the list with a small agenda:

1) Bug triage

Rather than list the (~18) known bugs here, I'll supply an URL (http://lampsvn.epfl.decenturl.com/scala-xml-bugs), and anyone who feels like their favourite bug merits further discussion should fire up a new topic on scala-xml and we'll start hashing it out.  If nobody pipes up I'll start posting individual emails regarding each bug with a few of my own comments in a few days.

2) Proposed enhancements

I'm sure many of us have a wish list of things we would like to see changed in Scala's XML support--please feel free to join in and tell us all about them.

Thanks for your time,

-0xe1a

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com

Ricky,

That works for me. Is there a corresponding relational binding?

Best wishes,

--greg

On Fri, Jan 30, 2009 at 11:55 PM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Isn't Scala's XML already linq-like support for XQuery?

An XQuery example from wikipedia:

<html><head/><body>
{
  for $act in doc("hamlet.xml")//ACT
  let $speakers := distinct-values($act//SPEAKER)

  return
    <div>
      <h1>{ string($act/TITLE) }</h1>
      <ul>
      {
        for $speaker in $speakers
        return <li>{ $speaker }</li>
      }
      </ul>


    </div>
}
</body></html>

A port to Scala:

<html><head/><body>
{
  for { act <- doc("hamlet.xml") \\ "ACT"
        speakers = distinctValues(act \\ "SPEAKER") }


      yield
        <div>
          <h1>{ act \ "TITLE" }</h1>
          <ul>
          {
            for (speaker <- speakers)
              yield <li>{ speaker }</li>


          }
          </ul>
        </div>
}
</body></html>

2009/1/31 Meredith Gregory <lgreg.meredith@gmail.com>

Alex,

This is probably way out of scope, but since someone brought up XPath, i couldn't resist... LINQ-like support for XQuery?

Best wishes,

--greg

On Fri, Jan 30, 2009 at 3:34 PM, Alex Cruise <alex@cluonflux.com> wrote:

Hi folks!

I'm Alex Cruise (obviously!) I'm a software architect at http://www.layer7tech.com/ (located in Vancouver, Canada) and have been hanging around the Scala community for about a year and a half.  I have recently volunteered to serve as a coordinator for the Scala XML team.  At this time, the XML team (apart from EPFL people, of course) consists of myself, Michael Fogus, Normen Müller and (I think) David Pollak, but contributions--including bug reports, patches, complaints, feature requests and existential angst--are of course welcome from everyone.

On behalf of said team, I would like to invite everyone who is interested in Scala's XML support to join the new scala-xml list!  (This post cc'd to scala and liftweb--the latter because the Lift project is easily one of the heaviest users of scala.xml, and I'm certain that members of that community will enthusiastically join in the discussion in short order. :)  If you'd like to watch the sausage being made, or even turn the crank a bit yourself, please subscribe to scala-xml by sending an empty email to scala-xml-subscribe@listes.epfl.ch .

Here's some background info for anyone who is unfamiliar with Scala's XML support:  The Scala compiler supports XML literals in Scala source files, with very few additional restrictions on their syntax.  XML literals are translated into a tree built from instances of several classes in the scala.xml package (http://www.scala-lang.org/docu/files/api/scala/xml$package.html), and may contain nested Scala expressions (each of which can also incorporate sub-nested XML literals, etc...) whose results are interpolated into the XML.

The scala.xml.Node class and its descendants form a comparatively lightweight, immutable, DOM-like representation of XML that can be used in pattern matching and provide simple, XPath-like node selection queries. The package also contains a few parsers and other assorted tools.

IMO we owe a debt of gratitude to Burak Emir, the primary developer of scala.xml.  I believe he has laid a solid foundation that will serve us well.  Burak also wrote http://burak.emir.googlepages.com/scalaxbook.docbk.html which gives insight into the rationale behind the design and implementation of the library.

Now, let's kick off the list with a small agenda:

1) Bug triage

Rather than list the (~18) known bugs here, I'll supply an URL (http://lampsvn.epfl.decenturl.com/scala-xml-bugs), and anyone who feels like their favourite bug merits further discussion should fire up a new topic on scala-xml and we'll start hashing it out.  If nobody pipes up I'll start posting individual emails regarding each bug with a few of my own comments in a few days.

2) Proposed enhancements

I'm sure many of us have a wish list of things we would like to see changed in Scala's XML support--please feel free to join in and tell us all about them.

Thanks for your time,

-0xe1a

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com

(de-cc'd scala-xml and liftweb)

Meredith Gregory wrote:
> That works for me. Is there a corresponding relational binding?
Ricky's answer is a good example of a nice principle, namely that where
Scala already has good generalized support for something, we should try
to leverage that into the XML realm, rather than trying to cook up our
own support for more meta-domain-specific dialects. :)

Anyway, assuming you're talking about RDBMS's, there have been several
attempts at a Scala database connectivity layer.

scala.dbc is in the standard library, but ISTR discouraging noises being
made about it. :)

http://scala.sygneca.com/libs/dbc describes DBC2, which Gilles Dubochet
is (was?) working on but it seems to have gone quiet. Harshad picked it
up for awhile at http://www.nabble.com/DBC-2-td20393411.html .

There are some bloggers working in this area too...
http://szeiger.de/blog/2008/12/21/a-type-safe-database-query-dsl-for-scala/
http://jackcoughonsoftware.blogspot.com/2008/12/fun-dsl-query-language-f...

It would be great for the stakeholders in this area to spend some time
arguing about the various proposals; if some kind of consensus could be
reached we could end up with another little gem of a library to show the
world. :)

-0xe1a

> On Fri, Jan 30, 2009 at 11:55 PM, Ricky Clarkson
> > wrote:
>
> Isn't Scala's XML already linq-like support for XQuery?
>
> An XQuery example from wikipedia:
>
>
> {
> for $act in doc("hamlet.xml")//ACT
> let $speakers := distinct-values($act//SPEAKER)
>
> return
>
>

{ string($act/TITLE) }

>

> {
> for $speaker in $speakers
> return
• { $speaker }

> }
>

>
>
>
> }
>
>
>
> A port to Scala:
>
>
> {
> for { act <- doc("hamlet.xml") \\ "ACT"
> speakers = distinctValues(act \\ "SPEAKER") }
>
>
> yield
>
>

{ act \ "TITLE" }

>

> {
> for (speaker <- speakers)
> yield
• { speaker }

>
>
> }
>

>
> }
>
>
>
> 2009/1/31 Meredith Gregory >
>
> Alex,
>
> This is probably way out of scope, but since someone brought
> up XPath, i couldn't resist... LINQ-like support for XQuery?
>
> Best wishes,
>
> --greg
>
> On Fri, Jan 30, 2009 at 3:34 PM, Alex Cruise
> > wrote:
>
> Hi folks!
>
> I'm Alex Cruise (obviously!) I'm a software architect at
> http://www.layer7tech.com/ (located in Vancouver, Canada)
> and have been hanging around the Scala community for about
> a year and a half. I have recently volunteered to serve
> as a coordinator for the Scala XML team. At this time,
> the XML team (apart from EPFL people, of course) consists
> of myself, Michael Fogus, Normen Müller and (I think)
> David Pollak, but contributions--including bug reports,
> patches, complaints, feature requests and existential
> angst--are of course welcome from everyone.
>
> On behalf of said team, I would like to invite everyone
> who is interested in Scala's XML support to join the new
> scala-xml list! (This post cc'd to scala and liftweb--the
> latter because the Lift project is easily one of the
> heaviest users of scala.xml, and I'm certain that members
> of that community will enthusiastically join in the
> discussion in short order. :) If you'd like to watch the
> sausage being made, or even turn the crank a bit yourself,
> please subscribe to scala-xml by sending an empty email to
> scala-xml-subscribe@listes.epfl.ch
> .
>
> Here's some background info for anyone who is unfamiliar
> with Scala's XML support: The Scala compiler supports XML
> literals in Scala source files, with very few additional
> restrictions on their syntax. XML literals are translated
> into a tree built from instances of several classes in the
> scala.xml package
> (http://www.scala-lang.org/docu/files/api/scala/xml$package.html),
> and may contain nested Scala expressions (each of which
> can also incorporate sub-nested XML literals, etc...)
> whose results are interpolated into the XML.
>
> The scala.xml.Node class and its descendants form a
> comparatively lightweight, immutable, DOM-like
> representation of XML that can be used in pattern matching
> and provide simple, XPath-like node selection queries. The
> package also contains a few parsers and other assorted tools.
>
> IMO we owe a debt of gratitude to Burak Emir, the primary
> developer of scala.xml. I believe he has laid a solid
> foundation that will serve us well. Burak also wrote
> http://burak.emir.googlepages.com/scalaxbook.docbk.html
> which gives insight into the rationale behind the design
> and implementation of the library.
>
> Now, let's kick off the list with a small agenda:
>
> 1) Bug triage
>
> Rather than list the (~18) known bugs here, I'll supply an
> URL (http://lampsvn.epfl.decenturl.com/scala-xml-bugs),
> and anyone who feels like their favourite bug merits
> further discussion should fire up a new topic on scala-xml
> and we'll start hashing it out. If nobody pipes up I'll
> start posting individual emails regarding each bug with a
> few of my own comments in a few days.
>
> 2) Proposed enhancements
>
> I'm sure many of us have a wish list of things we would
> like to see changed in Scala's XML support--please feel
> free to join in and tell us all about them.
>
> Thanks for your time,
>
> -0xe1a
>
>
>
>
> --
> L.G. Meredith
> Managing Partner
> Biosimilarity LLC
> 806 55th St NE
> Seattle, WA 98105
>
> +1 206.650.3740
>
> http://biosimilarity.blogspot.com
>
>
>
>
>

Alex,

Actually, i realized after i responded to Ricky's note that the story is a little more complicated if you take transactional semantics into account. It's certainly a good beginning, however. Interestingly, i think that the XQuery update story is considerably less compelling. Perhaps Scala might be a place to investigate a cleaner proposal.

Best wishes,

--greg

On Sat, Jan 31, 2009 at 3:13 PM, Alex Cruise <alex@cluonflux.com> wrote:

(de-cc'd scala-xml and liftweb)

Meredith Gregory wrote:

That works for me. Is there a corresponding relational binding?

Ricky's answer is a good example of a nice principle, namely that where Scala already has good generalized support for something, we should try to leverage that into the XML realm, rather than trying to cook up our own support for more meta-domain-specific dialects. :)

Anyway, assuming you're talking about RDBMS's, there have been several attempts at a Scala database connectivity layer.
scala.dbc is in the standard library, but ISTR discouraging noises being made about it. :)

http://scala.sygneca.com/libs/dbc describes DBC2, which Gilles Dubochet is (was?) working on but it seems to have gone quiet.  Harshad picked it up for awhile at http://www.nabble.com/DBC-2-td20393411.html .

There are some bloggers working in this area too...
http://szeiger.de/blog/2008/12/21/a-type-safe-database-query-dsl-for-scala/
http://jackcoughonsoftware.blogspot.com/2008/12/fun-dsl-query-language-for-scala.html

It would be great for the stakeholders in this area to spend some time arguing about the various proposals; if some kind of consensus could be reached we could end up with another little gem of a library to show the world. :)

-0xe1a

On Fri, Jan 30, 2009 at 11:55 PM, Ricky Clarkson <ricky.clarkson@gmail.com <mailto:ricky.clarkson@gmail.com>> wrote:

   Isn't Scala's XML already linq-like support for XQuery?

   An XQuery example from wikipedia:

   <html><head/><body>
   {
     for $act in doc("hamlet.xml")//ACT
     let $speakers := distinct-values($act//SPEAKER)

     return
       <div>
         <h1>{ string($act/TITLE) }</h1>
         <ul>
         {
           for $speaker in $speakers
           return <li>{ $speaker }</li>
         }
         </ul>


       </div>
   }
   </body></html>


   A port to Scala:

   <html><head/><body>
   {
     for { act <- doc("hamlet.xml") \\ "ACT"
           speakers = distinctValues(act \\ "SPEAKER") }


         yield
           <div>
             <h1>{ act \ "TITLE" }</h1>
             <ul>
             {
               for (speaker <- speakers)
                 yield <li>{ speaker }</li>


             }
             </ul>
           </div>
   }
   </body></html>
       
   2009/1/31 Meredith Gregory <lgreg.meredith@gmail.com
   <mailto:lgreg.meredith@gmail.com>>

       Alex,

       This is probably way out of scope, but since someone brought
       up XPath, i couldn't resist... LINQ-like support for XQuery?

       Best wishes,

       --greg

       On Fri, Jan 30, 2009 at 3:34 PM, Alex Cruise
       <alex@cluonflux.com <mailto:alex@cluonflux.com>> wrote:

           Hi folks!

           I'm Alex Cruise (obviously!) I'm a software architect at
           http://www.layer7tech.com/ (located in Vancouver, Canada)
           and have been hanging around the Scala community for about
           a year and a half.  I have recently volunteered to serve
           as a coordinator for the Scala XML team.  At this time,
           the XML team (apart from EPFL people, of course) consists
           of myself, Michael Fogus, Normen Müller and (I think)
           David Pollak, but contributions--including bug reports,
           patches, complaints, feature requests and existential
           angst--are of course welcome from everyone.

           On behalf of said team, I would like to invite everyone
           who is interested in Scala's XML support to join the new
           scala-xml list!  (This post cc'd to scala and liftweb--the
           latter because the Lift project is easily one of the
           heaviest users of scala.xml, and I'm certain that members
           of that community will enthusiastically join in the
           discussion in short order. :)  If you'd like to watch the
           sausage being made, or even turn the crank a bit yourself,
           please subscribe to scala-xml by sending an empty email to
           scala-xml-subscribe@listes.epfl.ch
           <mailto:scala-xml-subscribe@listes.epfl.ch> .

           Here's some background info for anyone who is unfamiliar
           with Scala's XML support:  The Scala compiler supports XML
           literals in Scala source files, with very few additional
           restrictions on their syntax.  XML literals are translated
           into a tree built from instances of several classes in the
           scala.xml package
           (http://www.scala-lang.org/docu/files/api/scala/xml$package.html),
           and may contain nested Scala expressions (each of which
           can also incorporate sub-nested XML literals, etc...)
           whose results are interpolated into the XML.

           The scala.xml.Node class and its descendants form a
           comparatively lightweight, immutable, DOM-like
           representation of XML that can be used in pattern matching
           and provide simple, XPath-like node selection queries. The
           package also contains a few parsers and other assorted tools.

           IMO we owe a debt of gratitude to Burak Emir, the primary
           developer of scala.xml.  I believe he has laid a solid
           foundation that will serve us well.  Burak also wrote
           http://burak.emir.googlepages.com/scalaxbook.docbk.html
           which gives insight into the rationale behind the design
           and implementation of the library.

           Now, let's kick off the list with a small agenda:

           1) Bug triage

           Rather than list the (~18) known bugs here, I'll supply an
           URL (http://lampsvn.epfl.decenturl.com/scala-xml-bugs),
           and anyone who feels like their favourite bug merits
           further discussion should fire up a new topic on scala-xml
           and we'll start hashing it out.  If nobody pipes up I'll
           start posting individual emails regarding each bug with a
           few of my own comments in a few days.

           2) Proposed enhancements

           I'm sure many of us have a wish list of things we would
           like to see changed in Scala's XML support--please feel
           free to join in and tell us all about them.

           Thanks for your time,

           -0xe1a




       --        L.G. Meredith
       Managing Partner
       Biosimilarity LLC
       806 55th St NE
       Seattle, WA 98105

       +1 206.650.3740

       http://biosimilarity.blogspot.com

How does linq to sql take transactions into account?  I've never used it (only linq to objects and my own QuickCheck-like linq backend) but my expectation is that it doesn't, and transactions are handled by surrounding code.

2009/1/31 Meredith Gregory <lgreg.meredith@gmail.com>

Alex,

Actually, i realized after i responded to Ricky's note that the story is a little more complicated if you take transactional semantics into account. It's certainly a good beginning, however. Interestingly, i think that the XQuery update story is considerably less compelling. Perhaps Scala might be a place to investigate a cleaner proposal.

Best wishes,

--greg

On Sat, Jan 31, 2009 at 3:13 PM, Alex Cruise <alex@cluonflux.com> wrote:

(de-cc'd scala-xml and liftweb)

Meredith Gregory wrote:

That works for me. Is there a corresponding relational binding?

Ricky's answer is a good example of a nice principle, namely that where Scala already has good generalized support for something, we should try to leverage that into the XML realm, rather than trying to cook up our own support for more meta-domain-specific dialects. :)

Anyway, assuming you're talking about RDBMS's, there have been several attempts at a Scala database connectivity layer.
scala.dbc is in the standard library, but ISTR discouraging noises being made about it. :)

http://scala.sygneca.com/libs/dbc describes DBC2, which Gilles Dubochet is (was?) working on but it seems to have gone quiet.  Harshad picked it up for awhile at http://www.nabble.com/DBC-2-td20393411.html .

There are some bloggers working in this area too...
http://szeiger.de/blog/2008/12/21/a-type-safe-database-query-dsl-for-scala/
http://jackcoughonsoftware.blogspot.com/2008/12/fun-dsl-query-language-for-scala.html

It would be great for the stakeholders in this area to spend some time arguing about the various proposals; if some kind of consensus could be reached we could end up with another little gem of a library to show the world. :)

-0xe1a

On Fri, Jan 30, 2009 at 11:55 PM, Ricky Clarkson <ricky.clarkson@gmail.com <mailto:ricky.clarkson@gmail.com>> wrote:

   Isn't Scala's XML already linq-like support for XQuery?

   An XQuery example from wikipedia:

   <html><head/><body>
   {
     for $act in doc("hamlet.xml")//ACT
     let $speakers := distinct-values($act//SPEAKER)

     return
       <div>
         <h1>{ string($act/TITLE) }</h1>
         <ul>
         {
           for $speaker in $speakers
           return <li>{ $speaker }</li>
         }
         </ul>


       </div>
   }
   </body></html>


   A port to Scala:

   <html><head/><body>
   {
     for { act <- doc("hamlet.xml") \\ "ACT"
           speakers = distinctValues(act \\ "SPEAKER") }


         yield
           <div>
             <h1>{ act \ "TITLE" }</h1>
             <ul>
             {
               for (speaker <- speakers)
                 yield <li>{ speaker }</li>


             }
             </ul>
           </div>
   }
   </body></html>
       
   2009/1/31 Meredith Gregory <lgreg.meredith@gmail.com
   <mailto:lgreg.meredith@gmail.com>>

       Alex,

       This is probably way out of scope, but since someone brought
       up XPath, i couldn't resist... LINQ-like support for XQuery?

       Best wishes,

       --greg

       On Fri, Jan 30, 2009 at 3:34 PM, Alex Cruise
       <alex@cluonflux.com <mailto:alex@cluonflux.com>> wrote:

           Hi folks!

           I'm Alex Cruise (obviously!) I'm a software architect at
           http://www.layer7tech.com/ (located in Vancouver, Canada)
           and have been hanging around the Scala community for about
           a year and a half.  I have recently volunteered to serve
           as a coordinator for the Scala XML team.  At this time,
           the XML team (apart from EPFL people, of course) consists
           of myself, Michael Fogus, Normen Müller and (I think)
           David Pollak, but contributions--including bug reports,
           patches, complaints, feature requests and existential
           angst--are of course welcome from everyone.

           On behalf of said team, I would like to invite everyone
           who is interested in Scala's XML support to join the new
           scala-xml list!  (This post cc'd to scala and liftweb--the
           latter because the Lift project is easily one of the
           heaviest users of scala.xml, and I'm certain that members
           of that community will enthusiastically join in the
           discussion in short order. :)  If you'd like to watch the
           sausage being made, or even turn the crank a bit yourself,
           please subscribe to scala-xml by sending an empty email to
           scala-xml-subscribe@listes.epfl.ch
           <mailto:scala-xml-subscribe@listes.epfl.ch> .

           Here's some background info for anyone who is unfamiliar
           with Scala's XML support:  The Scala compiler supports XML
           literals in Scala source files, with very few additional
           restrictions on their syntax.  XML literals are translated
           into a tree built from instances of several classes in the
           scala.xml package
           (http://www.scala-lang.org/docu/files/api/scala/xml$package.html),
           and may contain nested Scala expressions (each of which
           can also incorporate sub-nested XML literals, etc...)
           whose results are interpolated into the XML.

           The scala.xml.Node class and its descendants form a
           comparatively lightweight, immutable, DOM-like
           representation of XML that can be used in pattern matching
           and provide simple, XPath-like node selection queries. The
           package also contains a few parsers and other assorted tools.

           IMO we owe a debt of gratitude to Burak Emir, the primary
           developer of scala.xml.  I believe he has laid a solid
           foundation that will serve us well.  Burak also wrote
           http://burak.emir.googlepages.com/scalaxbook.docbk.html
           which gives insight into the rationale behind the design
           and implementation of the library.

           Now, let's kick off the list with a small agenda:

           1) Bug triage

           Rather than list the (~18) known bugs here, I'll supply an
           URL (http://lampsvn.epfl.decenturl.com/scala-xml-bugs),
           and anyone who feels like their favourite bug merits
           further discussion should fire up a new topic on scala-xml
           and we'll start hashing it out.  If nobody pipes up I'll
           start posting individual emails regarding each bug with a
           few of my own comments in a few days.

           2) Proposed enhancements

           I'm sure many of us have a wish list of things we would
           like to see changed in Scala's XML support--please feel
           free to join in and tell us all about them.

           Thanks for your time,

           -0xe1a




       --        L.G. Meredith
       Managing Partner
       Biosimilarity LLC
       806 55th St NE
       Seattle, WA 98105

       +1 206.650.3740

       http://biosimilarity.blogspot.com

Ricky Clarkson wrote:
> How does linq to sql take transactions into account? I've never used
> it (only linq to objects and my own QuickCheck-like linq backend) but
> my expectation is that it doesn't, and transactions are handled by
> surrounding code.
This may be a naive thought, but I would think that most of the
"updates" (whether in-place mutations or transformations) you'd consider
making to an XML or other in-memory data structure should be confined to
a single thread, so the transaction abstraction wouldn't add any value.

If you really want to do in-place, concurrent modifications against any
non-trivial data structure, transactions are definitely worthwhile.

-0xe1a

I think Greg was talking specifically about databases there.

2009/1/31 Alex Cruise <alex@cluonflux.com>

Ricky Clarkson wrote:

How does linq to sql take transactions into account?  I've never used it (only linq to objects and my own QuickCheck-like linq backend) but my expectation is that it doesn't, and transactions are handled by surrounding code.

This may be a naive thought, but I would think that most of the "updates" (whether in-place mutations or transformations) you'd consider making to an XML or other in-memory data structure should be confined to a single thread, so the transaction abstraction wouldn't add any value.

If you really want to do in-place, concurrent modifications against any non-trivial data structure, transactions are definitely worthwhile.

-0xe1a

Alex,

Ricky's correct, i was speaking of a backing store. So, in the case of SQL, we are looking at a RDBMS, such as MySQL while in the case of XQuery we are looking at something like BDBXML.

Ricky,

You can probably get a reasonable factorization pushing commits to some surrounding context, but i need to think about this a bit more. i would certainly like a do-notation like widget in which what appears to be an atomic "assignment" makes a commit to store that the remainder of the straight line code can rely on to have happened.

Best wishes,

--greg

On Sat, Jan 31, 2009 at 3:46 PM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

I think Greg was talking specifically about databases there.

2009/1/31 Alex Cruise <alex@cluonflux.com>

Ricky Clarkson wrote:

How does linq to sql take transactions into account?  I've never used it (only linq to objects and my own QuickCheck-like linq backend) but my expectation is that it doesn't, and transactions are handled by surrounding code.

This may be a naive thought, but I would think that most of the "updates" (whether in-place mutations or transformations) you'd consider making to an XML or other in-memory data structure should be confined to a single thread, so the transaction abstraction wouldn't add any value.

If you really want to do in-place, concurrent modifications against any non-trivial data structure, transactions are definitely worthwhile.

-0xe1a

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com

Meredith Gregory wrote:
> Ricky's correct, i was speaking of a backing store. So, in the case of
> SQL, we are looking at a RDBMS, such as MySQL while in the case of
> XQuery we are looking at something like BDBXML.
Got it... So if you have a widely used root element you don't want to
lock out everybody who might be making changes way down in the guts of
the document.
> You can probably get a reasonable factorization pushing commits to
> some surrounding context, but i need to think about this a bit more. i
> would certainly like a do-notation like widget in which what appears
> to be an atomic "assignment" makes a commit to store that the
> remainder of the straight line code can rely on to have happened.
This is actually something I've been thinking about--without any
concrete result--for a long time. The challenge is how to safely
accomplish actual mutations in a complex object graph, in which calls to
"setters" are really deferred transformations, while presenting users
with an idiomatic OO view. After thinking about it for a depressingly
long time, I realized that STM was likely a big part of the answer; the
challenge then became how to expose STM functionality while retaining a
"look and feel" that's as OO-idiomatic as possible. Scala's implicits
would of course be able to play a big role here.

The JVSTM (http://web.ist.utl.pt/~joao.cachopo/jvstm/) guy has come up
with what I feel is a good compromise solution--he invented a Java-like
but intentionally limited language for describing classes
declaratively--without reference to STM--including their properties,
relationships and invariants, which is then fed into a code generator.
While code generation is often thought to result in two-way issues, he
makes a pretty good case for it.

At this point I'm waiting to see what Martin comes up with
(http://lampsvn.epfl.ch/trac/scala/changeset/16836/scalax) before I dive
back in to my futile wandering. :)

-0xe1a

Alex,

i think a bunch of concerns can be separated. There's transactional semantics and there's specification and modification of shape and concomitantly shape navigation. i'm not a fan of "objects". The notions of composition are mostly moribund and the putative benefits to software reuse are known to be at odds with concurrency.

For the specification of shape, algebraic data types cover 80% of the phenomena i have interest in. If you toss in various flavors of name-management/freshness technology, i've got coverage of nearly 90% of the phenomena i have a need to compute over on a regular basis. You can cover, for example, all the extant XML schema proposals with this basis.

For this shape set there are a rich set of generic navigation techniques from zipper to SYB to emgm.

For transactional technology, various STM stuff can be made to fit with backing store semantics, but STM is certainly not the be-all-and-end-all of transactional accounts. i did some work in the early '90's on relaxed transactions that ultimately underpinned a lot of the compensating transaction semantics in BizTalk.

The major question is how to package up these different capabilities into a coherent, usable idiom. That's where comprehensions + a do-notation seem to have an edge.

Best wishes,

--greg

On Sun, Feb 1, 2009 at 1:50 PM, Alex Cruise <alex@cluonflux.com> wrote:

Meredith Gregory wrote:

Ricky's correct, i was speaking of a backing store. So, in the case of SQL, we are looking at a RDBMS, such as MySQL while in the case of XQuery we are looking at something like BDBXML.

Got it... So if you have a widely used root element you don't want to lock out everybody who might be making changes way down in the guts of the document.

You can probably get a reasonable factorization pushing commits to some surrounding context, but i need to think about this a bit more. i would certainly like a do-notation like widget in which what appears to be an atomic "assignment" makes a commit to store that the remainder of the straight line code can rely on to have happened.

This is actually something I've been thinking about--without any concrete result--for a long time.  The challenge is how to safely accomplish actual mutations in a complex object graph, in which calls to "setters" are really deferred transformations, while presenting users with an idiomatic OO view.  After thinking about it for a depressingly long time, I realized that STM was likely a big part of the answer; the challenge then became how to expose STM functionality while retaining a "look and feel" that's as OO-idiomatic as possible.  Scala's implicits would of course be able to play a big role here.

The JVSTM (http://web.ist.utl.pt/~joao.cachopo/jvstm/) guy has come up with what I feel is a good compromise solution--he invented a Java-like but intentionally limited language for describing classes declaratively--without reference to STM--including their properties, relationships and invariants, which is then fed into a code generator.  While code generation is often thought to result in two-way issues, he makes a pretty good case for it.

At this point I'm waiting to see what Martin comes up with (http://lampsvn.epfl.ch/trac/scala/changeset/16836/scalax) before I dive back in to my futile wandering. :)

-0xe1a

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com