I presented a 5-min lightening talk at 2010-11-29 New York Scala Enthusiasts meetup with 8 others.
Here's the pdf of the slides. The presentation fell apart in the middle because the sample code text was too dark over the black background (corrected in pdf). Nonetheless it was inspiring to get live feedback and see what other hackers are up to.

• Generates typeclass-based XML data binding code in a separate file xmlprotocol.scala.
• Renames runtime package name from org.scalaxb.rt to scalaxb and the helper file to scalaxb.scala.
• Fixes handling of <xs:all> containing >22 items (GH-10).
• Fixes handling of <xs:complexType> containing >22 attribtues (GH-11).
• Fixes handling of <xs:complexType> with <xs:simpleContent>, which restricts a mixed <xs:complexContent> (GH-12).
• Fixes output instability (GH-13).

• Improves code generation for mixed contents by using parser combinators.
• Improves data binding for <any> when the values are XML Schema built-in simple types.
• Improves code generation for <choice> when all options can be narrowed down to a single type or a trait.
• --class-prefix and --param-prefix option to customize code generation.
• Includes scala-library into jar to avoid deployment issues.

Since I've heard several issues installing scalaxb via sbaz, which I think is attributed to Scala version incompatibility, I've decided to include scala-library into scalaxb.jar using sbt-proguard-plugin.

I added two command line options --class-prefix and --param-prefix to add prefixes to the generated code. It shouldn't be needed if the schema uses lower case for element names like many of the well-known schemas (slap me if you catch me say schemata or octopodes). This is because scalaxb capitalizes the class name, but leaves the params alone, so you'd end up with code like the following:

case class USAddress(name: String,
  street: String,
  city: String,
  usstate: USState,
  zip: Int) extends Addressable

rt.DataRecord came out of the necessity to fulfill two requirements. The first is to convert XML document into a native object so it could be consumed easier (also known as data binding); the second is to retain the ability to convert the native object back into the XML document (also known as round trip). The two requirements are sometimes not aligned with each other. For example, if I am just worried about getting the round trip done, I can just hold on to the scala.xml.Node and use that to write XML out, but it's not very useful from the data binding perspective.

The first goal of the scalaxb was to cover the full range of XML Schema and implementing the round trip. Now that the goal is mostly fulfilled, my recent updates were aimed to improve the usability of generated code while still maintaining the roundtripability. One area where the pendulum has shifted too much towards round trip is the code generated for <choice>. I'd like to review the history of code generation for <choice> and propose a new solution at the end.

In order for a DataRecord to not lose the freight during the round trip of <any>, I've been storing the scala.xml.Elem object within it. This is convenient for the round trip, but not for consuming the DataRecord. The problem with <any> is that it could be anything, and I wouldn't know how to parse them. At least when they are not built-in types.

Now that mixed contents have been cleaned up, it seemed like a good time to start parsing XSD built-in types too. Here's how it looks like:

def testAny {
  val subject = <foo xmlns="http://www.example.com/any"

scalaxb added support for mixed contents a while back. When <xs:complexType mixed="true">, text nodes are placed in conjunction with the subelements of the complex type, like XHTML. Since I implemented it, it's been bothering me that the generated case class is not DRY.

For example,

<xs:element name="mixedTest">
  <xs:complexType mixed="true">
    <xs:choice maxOccurs="unbounded">
      <xs:element name="billTo" type="Address"/>
      <xs:any namespace="##other" processContents="lax" />

• Implements support for <enumeration>.
• Implements support for substitution groups.
• Works around 22-parameter limitation by splitting up long sequences into chunks.

Earlier this year I wrote about hitting some scala limitations:

Scala supports only up to Tuple22.

This means that Scala can define case classes only up to 22 parameters. I've implemented workarounds to use schema that includes complex types that has more than 22 particles within the sequence.

First, when a sequence contains more than MaxParticleSize (20) particles, it will split up the sequence into chunks of ChunkParticleSize (10). For example, a sequence that has 30 elements would be split into three chunks of 10 elements: