ラウンド・トリップ

ラウンド・トリップ(往復券)の実装を始めています.つまり,xmlドキュメントからscalaオブジェクトに変換して,そこからまたxmlドキュメントに変換できるようにする機能です.以下のようなドキュメントがあるとして,

val subject = <shipTo xmlns="http://www.example.com/IPO"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:ipo="http://www.example.com/IPO"
    xsi:type="ipo:USAddress">
  <name>Foo</name>
  <street>1537 Paper Street</street>
  <city>Wilmington</city>
  <state>DE</state>
  <zip>19808</zip>
</shipTo>

fromXML()を呼び出すことでオブジェクトに変換できます

val obj = Addressable.fromXML(subject)

名前空間別パッケージ名

名前空間ごとに別のパッケージ内にクラスを生成できるようになりました.

  -p:<namespaceURI>=<package> | --package:<namespaceURI>=<package>
        specifies the target package for <namespaceURI>

例えばXML SignatureとSAML 2.0 assertionは別のパッケージの方がいいですね:

$ scalaxb -p:http://www.w3.org/2000/09/xmldsig#=org.w3.xmldsig -p:http://www.w3.org/2001/04/xmlenc#=org.w3.xmlenc -p:urn:oasis:names:tc:SAML:2.0:assertion=org.xml.saml2.assertion -p:urn:oasis:names:tc:SAML:2.0:metadata=org.xml.saml2.metadata saml-schema-metadata-2.0.xsd saml-schema-assertion-2.0.xsd xenc-schema.xsd xmldsig-core-schema.xsd 

attributes and namespaces in xml

I've heard on occasions that the way attributes work in XML is a mess. It is. The fault is not at attributes per se, but it's the way XML namespace is implemented that's confusing. The spec is called Namespaces in XML 1.0. Try to keep a straight face.

  1. Default namespace declarations do not apply directly to attribute names.
  2. The interpretation of unprefixed attributes is determined by the element on which they appear.
  3. The namespace name for an unprefixed attribute name always has no value.
  4. In all cases, the local name is local part.
  5. No tag may contain two attributes which have identical names.
  6. No tag may contain two attributes which have qualified names with the same local part and with prefixes which have been bound to namespace names that are identical.
  7. All element and attribute names contain either zero or one colon.
  8. No attributes with a declared type of ID, IDREF(S), ENTITY(IES), or NOTATION contain any colons.

<import>, <any>, and simple types

Finally implemented some rough cut of the <import> support. The process is looking more and more like a language compiler. When you are processing multiple XSD schema, the actual parsing step doesn't really care about other files, but the type checking/object binding phase needs to be aware of the other schemas.

In the schema, all you have to do is write

<import namespace="http://www.example.com/IPO"/>

and the types etc. from the given namespace are imported to the current schema. So, this works more like Java's import than C's #include, which is limited to inclusion of a physical file.

xml namespace

I've been working on Issue 1 submitted by Tsuresh Kumar for a while now. The idea is to compile the schema for SAML Metadata, which is saml-schema-metadata-2.0.xsd. I need to implement a few things so scalaxb can handle the schema.

scala, maven, and netbeans

I've been coding scala using TextMate with ant or simple-build-tool, but I'd like to give NetBeans a try again. Coding without IDE wasn't as bad, since the compiler and tests can catch undefined symbols and typos while making code changes; however, that's not to say it was perfect. I had to go back and forth between the scaladoc and TextMate in situation I could have just let IDE autocompletion look things up. Also navigating between error messages and the code has been slow, especially since I moved to sbt, which is not integrated with TextMate.

parsing parameter using scopt

Of three command line parameter parsing libraries that I found in Scala, I found jstrachan/scopt to be the best one out there: lightweight and easy to use. The new feature I will be working on, however required -x:key=value option, which was not supported by scopt. The great thing about opensource is that I can just add the new feature if I want to, and github makes it so easy to fork and add a few things in.

simple-build-tool (sbt) and scala bazaar system (sbaz)

Now that I could compile files and evaluate thing from specs, I wanted to create a sbaz package to completely replace Ant.

simple-build-tool (sbt) and specs

somewhat updated

Some people land on this page searching for "sbt specs" on Google, so I feel somewhat obligated to update the info on this page.

First of all, as of 2011, the specs signature in Project file looks like:

    val specsVersion = crossScalaVersionString match {
      case "2.8.0" => "1.6.5"
      case _ => "1.6.6"
    }
    val specs = "org.scala-tools.testing" % ("specs_" + crossScalaVersionString) % specsVersion % "test"

hitting some scala limitations

Fixing salaxb so it can compile Footprint XML Specification.

First I had to account for the fact that in XML Schema, you could legally have elements having the same name as long as they are not at the top level. This required me to change the parsing a little bit. Next, I was fixing the simple content handling, I ran into the following error message by Scala compiler:

   [scalac] tests/tmp/footprint.scala:255: error: value Tuple23 is not a member of package scala 
   [scalac] case class VolunteerOpportunity(volunteerOpportunityID: Option[String],
   [scalac]            ^
   [scalac] one error found

This is because Scala supports only up to Tuple22.

Syndicate content