multiple schema files

This page explains a single execution of scalaxb that involves multiple schema files. For multiple runs of scalaxb, see multiple configs.

<xs:include> and <xs:import>

In XML Schema, schema components for a single target namespace can be assembled from multiple schema definition documents using <xs:include>. For example XML Schema translation of MathML 3's mathml3-content.xsd contains the following:

<xs:include schemaLocation="mathml3-strict-content.xsd"/> 

navigating XML Schema

This is a memo to navigate around the case classes for XML Schema. Besides the derivation by extension that programming languages have as inheritance, XML Schema also allows derivation by restriction. Since Scala I don't think expresses this easily, some types are wider than how they are specified in the schema.


  • known subclasses: XTopLevelElement, XLocalElementable, XNarrowMaxMin, XLocalElement
  • value member: xelementoption : Option[DataRecord[XElementOption]]

typeclass-based XML data binding

Ultimately, the users of scalaxb are interested the real problems that the entity objects express, not how they persist into XML. That's why I knew I eventually had to vacate the singleton/companion object of the case class to implement the data binding. Until recently it has been generating the data binding implementation as follows:

object Address extends rt.ElemNameParser[Address] {
  val targetNamespace = ""
  def parser(node: scala.xml.Node): Parser[Address] =

scalaxb 0.5.1

  • Command line program uses Scala 2.8.1.
  • Fixes accessors to compositors by using type name as the param name. (GH-18)
  • Fixes generated type of nillable varargs. (also GH-18)

slides for 2010-11-29 ny-scala

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.

scalaxb 0.5.0

  • 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).

scalaxb 0.4.0


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.

--class-prefix and --param-prefix

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

narrower <choice>

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.

Syndicate content