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.

<any> revisited

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"

mixed content revisited

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" />

scalaxb 0.3.0

working around Tuple22 limitation

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:

substitution group

XML Schema Part 0: Primer:

XML Schema provides a mechanism, called substitution groups, that allows elements to be substituted for other elements. More specifically, elements can be assigned to a special group of elements that are said to be substitutable for a particular named element called the head element. (Note that the head element as well as the substitutable elementsmust be declared as global elements.)

The following demonstrates substitution group:

<complexType name="GH6Usage">
  <sequence>

<enumeration>

XML Schema Part 0: Primer:

The enumeration facet limits a simple type to a set of distinct values. For example, we can use the enumeration facet to define a new simple type called USState, derived from string, whose value must be one of the standard US state abbreviations:

<xsd:simpleType name="USState">
  <xsd:restriction base="xsd:string">
    <xsd:enumeration value="AK"/>
    <xsd:enumeration value="AL"/>
    <xsd:enumeration value="AR"/>
    <!-- and so on ... -->
  </xsd:restriction>

scalaxb-appengine

scalaxb-appengine is a RESTful API to run scalaxb over the web. It's implemented using n8han/Unfiltered and the full source is available on eed3si9n/scalaxb.

compile

URL:
http://scalaxb.appspot.com/compile/{output}.{format}
Formats:
scala, zip
HTTP method:
POST
HTTP encoding:
multipart/form-data
Parameters:
- arg: Optional, multiple allowed. URL of the schema file.
- argf: Optional, multiple allowed. Uploaded schema file.
- defaultPackageName: Optional. Name of the target package.
- namespaceURI: Optional, multiple allowed. URI of namespace to be packaged.
- packageName: Optional, multiple allowed. Name of the target package for the namespaceURI.
- classPrefix: Optional. Prefixes generated class names.
- paramPrefix: Optional. Prefixes generated parameter names.
- wrapContents: Optional, multiple allowed. Wraps inner contents into a seperate case class.
Notes:
- At least one arg or argf must be present.
- The n-th packageName specifies the target package for the n-th namespaceURI.

scalaxb 0.2.0

  • Implements support for <group>, <attributeGroup>, and <all>.
  • Fixed round trip of complex types containing sequences.
  • Generates toXML into the companion objects to simplify the case class.

For example,

<xs:complexType name="Address">
  <xs:sequence>
    <xs:element name="name"   type="xs:string"/>
    <xs:element name="street" type="xs:string"/>
    <xs:element name="city"   type="xs:string"/>
  </xs:sequence>
</xs:complexType>

turns to

case class Address(name: String,

<group> and <attributeGroup>

From XML Schema Part 1:

The XML representation for a model group definition schema component is a <group> element information item. It provides for naming a model group for use by reference in the XML representation of complex type definitions and model groups.

The <group> construct allows the schema designers to reuse part of the content model without resorting to type derivation. This comes in handy when dealing with complicated schema. Suppose we have a group named head.misc and an element named head.

Syndicate content