scalaxb 0.5.2

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

複数のスキーマファイル

<xs:include> and <xs:import>

XML Schema では、<xs:include> を用いることで、一つの対象名前空間のためのスキーマを複数のスキーマ定義ドキュメントを組み合わせて定義することができる。例えば、MathML 3 のスキーマの XML Schema 版は以下を含む:

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

これは、mathml3-strict-content.xsd をあたかもスキーマの一部であるかのように取り込む。

また、XML Schema では、スキーマ定義ドキュメントは <xs:import> を用いることで他の名前空間のスキーマを参照することができ、つまり他のスキーマ定義ドキュメントを参照することができる。例えば、SAML Assertion のスキーマは二つの外部スキーマ定義をインポートする:

<import namespace="http://www.w3.org/2000/09/xmldsig#"

型クラスによる XML データバインディング

結局の所,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 データバインディングのために一等地をハイジャックしてしまったのだ.

scalaxb 0.5.1

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

scalaxb 0.5.0

  • 型クラスによって 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).

scalaxb 0.4.0

proguard

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

--class-prefix と --param-prefix

生成されるコードにプリフィックスを加えるため,--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

<choice> の限定

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

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

<any>,再び

<any> のラウンド・トリップにおいて貨物を無くさないために,DataRecord中に scala.xml.Elem を保存してきましたが,DataRecord を利用する側に立つと,これは不便でもあります.問題は <any> はどの要素が来てもいいためパース不可能なことです.ただし,組み込み型はパース可能です.

混在内容のカタがある程度ついたので,XSD 組み込み型のパースに手をつけるいい機会だと思いました.使用例は以下のようになります:

def testAny {
  val subject = <foo xmlns="http://www.example.com/any"
      xmlns:xs="http://www.w3.org/2001/XMLSchema"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <int xsi:type="xs:int">1</int>
        <byte xsi:type="xs:byte">1</byte>
        <dateTime xsi:type="xs:dateTime">2002-10-10T12:00:00Z</dateTime>
Syndicate content