互換性の無い変更点 (no import)

• 補助関数を Scalaxb オブジェクトから scalaxb パッケージオブジェクトに移した。
• デフォルトの型クラスインスタンスを DefaultXMLProtocol trait から生成されるクラスのパッケージオブジェクトに移した。(#nescala での @jsuereth参照)

以前の使用例:

import scalaxb._
import Scalaxb._
import ipo._
import DefaultXMLProtocol._
val shipTo = fromXML[Address](subject)

今後の使用例:

val shipTo = scalaxb.fromXML[ipo.Address](subject)

バグフィクスおよび細かな機能改善点

• xs:integer その他を BigInt に対応させた。
• 代替グループのパーシングを修正した。(GH-25: 報告者 @dbolene)
• attributeFormDefault、elementFormDefault、form のサポートを実装した。(GH-26: 報告者 @dbolene)
• 長いシーケンスのパーシングを修正した。(GH-29: 報告者 E-Fir)
• UTF-8 と UTF-16 における BOM の取り扱いを実装した。(GH-31: 報告者 @fredferrao)
• バージョン番号を表示する。 (GH-24: 報告者 @dbolene)
• パーサーのエラーメッセージを改善した。(GH-27: 報告者 @dbolene)

• <xs:sequence> の取り扱いを修正しました。(GH-19)
• <xs:attributeGroup> の取り扱いを修正しました。 (GH-21)
• 参照されたスキーマやコンポーネントが見つからない場合のエラーメッセージを改善しました。
• 見つからないスキーマを現ディレクトリ内で検索するようにしました。(GH-23)

結局の所，scalaxb のユーザはエンティティ・オブジェクトが表現する現実の問題に興味があるのであって，それがどう XML に永続化されるかといったことではない．だから，いつかデータバインディングの実装をシングルトン/コンパニオン・オブジェクトから追い出さなければいけないことは分かっていた．つい最近までデータバインディングの実装は以下のように生成されていた:

object Address extends rt.ElemNameParser[Address] {
  val targetNamespace = "http://www.example.com/IPO"
 
  def parser(node: scala.xml.Node): Parser[Address] =
    ...
 
  def toXML(__obj: Address, __namespace: String, __elementLabel: String, __scope: scala.xml.NamespaceBinding): scala.xml.NodeSeq =
    ...
}

つまり，scalaxb は Address そのものとは関係の無い XML データバインディングのために一等地をハイジャックしてしまったのだ．

• コマンドラインプログラムが Scala 2.8.1 を使うようになりました．
• パラメタ名に型の名前を使うことでコンポジターのアクセス子を修正しました．(GH-18)
• ニラブルな可変長引数の型を修正しました．(同じく，GH-18)

• 型クラスによって XML データバインディングを行うコードを xmlprotocol.scala という別のファイルに生成します．
• ランタイムの package を org.scalaxb.rt から scalaxb という名前に変更して，また補助ファイルを scalaxb.scala という名前に変えました．
• >22 のアイテムを含む <xs:all> の取り扱いを修正しました (GH-10)．
• >22 の属性を含む <xs:complexType> の取り扱いを修正しました (GH-11)．
• <xs:complexContent> を制限する <xs:simpleContent> を含んだ <xs:complexType> の取り扱いを修正しました (GH-12)．
• 生成されるコードの揺れを修正しました (GH-13)．
• XML データバインディングを行うコードを一つの trait にまとめることで循環 <xs:import> の取り扱いを修正しました (GH-14)．
• <xs:include> に指定されたスキーマがコンパイルに含まれていない場合に警告を出すようにしました (GH-15)．

• パーサ・コンビネータを使って混在内容のコード生成を改良しました．
• XML Schema 組み込み型を値の場合の <any> のデータ・バインディングを改良しました．
• 選択肢が単一のクラスか trait に限定される場合の <choice> のコード生成を改良しました．
• コード生成をカスタマイズする --class-prefix と --param-prefix のオプションを加えました．
• デプロイ時の問題を回避するため scala-library を jar に含めました．

恐らく Scala バージョンが合わなかったことに起因する sbaz を使った scalaxb インストールの問題が前に何例か報告されたので scala-library を sbt-proguard-plugin を使って scalaxb.jar の中に入れてしまうことにしました．

生成されるコードにプリフィックスを加えるため，--class-prefix と --param-prefix の二つのオプションを追加しました．主要なスキーマのように要素名に小文字を使っていればこのオプションは必要になることはないと思います．scalaxb はクラス名の語頭を大文字にしますが，パラメータ名はいじらないため，以下のようなコードになるためです:

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

要素名の語頭がスキーマの中でも大文字化されているとすると，以下のようなコードになってしまいます:

case class USAddress(Name: String,
  Street: String,
  City: String,
  USState: USState,
  Zip: Int) extends Addressable

XML ドキュメントを利用しやすいネイティブなオブジェクトに変換（データ・バインディング）する，そしてそのオブジェクトを XML ドキュメントに逆変換（ラウンド・トリップ）できる能力を保持するという二つの要請から rt.DataRecord は 生まれました．しかし，この二つの要件は時として統一的な行動を取りません．例えば，逆変換のことだけを考えてしまうと，XML を書き出すために scala.xml.Node を保持すれば解決してしまいますが，データ・バインディングという立場から見ると便利なものではありません．

scalaxb の当初の目標は XML Schema の表現空間をカバーして，かつラウンド・トリップを実装することでした．この目標はほぼ達成されたので，最近の更新では逆変換性は保持しつつ，生成されたコードの利便性を高めることを目指してきました．ラウンド・トリップ側に傾き過ぎたものの一つに <choice> のコード生成があります．まずはこれまでの <choice> のコード生成の歴史を振り返り，最後に新しい案を提起したいと思います．