dev >> XML

XslCompiledTransform で xsl:output の設定内容を反映させるには

THREE-ONE — Mon, 08 Sep 2008 16:36:00 GMT

XslCompiledTransform.Transform では、出力先が XmlWriter の場合、ロードした xsl:output の設定内容はデフォルトでは反映されない。
OutputSettings プロパティに、output 要素の設定内容が格納されているので、XmlWriter.Create 時に渡してやる必要がある。これで DOCTYPE を指定したり、xml 宣言を出力しないようにできる。
特に DOCTYPE を指定するのは、XmlWriterSettings じゃできないので注意。

xsd:enumeration

THREE-ONE — Sat, 07 Jul 2007 16:46:00 GMT

制約ファセットで一つ忘れてました。
enumeration 制約ファセットなるものがあります。
これは、特定の値しか設定させないという制約ファセットです。

<xsd:attribute name="Enabled">
    <xsd:restriction type="xsd:string">
        <xsd:simpleType>
            <xsd:enumeration value="True"/>
            <xsd:enumeration value="False"/>
        </xsd:simpleType>
    </xsd:restriction>
</xsd:attribute>

このような、属性定義を行うと Enabled 属性には True か False しか設定できなくなります。

<xsd:attribute name="nowrap">
    <xsd:restriction type="xsd:string">
        <xsd:simpleType>
            <xsd:enumeration value="nowrap"/>
        </xsd:simpleType>
    </xsd:restriction>
</xsd:attribute>

とすれば一応下記と同値になるのかな？（やんないけどね）

<xsd:attribute name="nowrap" type="xsd:string" fixed="nowrap"/>

制約ファセット（その２：正規表現編）

THREE-ONE — Sat, 23 Jun 2007 16:00:00 GMT

制約ファセットに pattern ファセットがあります。
これは正規表現を扱う制約ファセットなのですが、非常に強力です。
XML は所詮テキストなので、正規表現が利用できるとかなり便利なのは想像に難くないですね。
一般的な正規表現については割愛します。

ここでは、あまりなじみのない特殊な正規表現を紹介します。

【Unicode のカテゴリーで指定する】
\p{カテゴリー名} で指定されたカテゴリーに所属する文字を、\P{カテゴリー名} で指定されたカテゴリーに所属しない文字を指定することができます。
例えば、\p{Lu} なら大文字アルファベット、\p{Nd} なら数字、\P{Ll} なら小文字アルファベット以外の文字といった具合です。

【Unicode のブロックで指定する】
\p{Isブロック名} で指定されたブロックに所属する文字を、\P{Isブロック名} で指定されたブロックに所属しない文字を指定することができます。
\p{IsGreek} ならギリシャ語、\p{IsHiragana} ならひらがな、\P{IsKatakana} ならカタカナ以外の文字といった具合です。
詳しくは http://www.unicode.org/charts/ で確認してみてください。

【文字クラスの減算】
様々な文字クラスを集合の減算のように扱えます。
[\p{Nd}-[0]] で 0 以外の数字、[\p{IsBasicLatin}-[\p{Nd}]] で BasicLatin ブロックから数字を除いたものを指定できます。

そして、これらは .NET Framework の System.Text.RegularExpressions.Regex クラスでも利用できます。
\p{IsHiragana}, \p{IsKatakana} あたりは、入力値のバリデートに利用できそうですね。
文字クラスの減算はできないと思ってたんですが、どうやら .NET 2.0 から利用できるようになったみたいですね。

// .NET 1.x
Console.WriteLine(Regex.IsMatch("hogeA", "^[\\p{IsBasicLatin}-[A]]+$")); // False
Console.WriteLine(Regex.IsMatch("hogeB", "^[\\p{IsBasicLatin}-[A]]+$")); // False

// .NET 2.0
Console.WriteLine(Regex.IsMatch("hogeA", "^[\\p{IsBasicLatin}-[A]]+$")); // False
Console.WriteLine(Regex.IsMatch("hogeB", "^[\\p{IsBasicLatin}-[A]]+$")); // True

こんなふうになりました。

ちなみに Java だと、java.util.regex パッケージでは、文字クラスの減算はできません。
また、ブロック指定もプレフィクスが Is ではなく In になります。
ですが、Xerces で XML Schema を利用する際には、どちらも利用できます。
どうも Xerces 内部の org.apache.xerces.impl.xpath.regex.RegularExpression あたりが司ってそうな感じです。
ただ、パッケージが xpath ってのが気になるところではありますが。
直接 Java ソースから利用できるかなーと思ってみたんですが、めんどくさくなってあきらめました。
ちゃんと環境設定してやればできるんじゃないかなー

制約ファセット（その１）

THREE-ONE — Wed, 20 Jun 2007 17:01:00 GMT

XML で要素内容や属性値をデータ型以上に制限したいときがあります。
たとえば、数値の上限を定めたかったり、文字数の下限・上限を定めた飼ったりする場合ですね。
そんな場合、独自データ型というものを作成します。
独自に単純型を定義する場合、基本的には「制限(ristriction)」という手段を用いて定義します。
そのとき利用するものが制約ファセットです。
制約ファセットは全て下記の記述で表現されます。

<xsd:制約名 value="利用する値"/>

そしてそれぞれの制約は、利用する際に基となるデータ型はほぼ決まっています。
各数値のデータ型、もしくは文字列型です。
数値の場合、minInclusive（以下）, minExclusive（未満）, maxInclusive（以上）, maxExclusive（より上）, totalDigits（桁総数）, fractionDigits（小数部の桁数）が利用できます。
文字列の場合、length, maxLength, minLength, pattern ですね。minLength や maxLength は指定された値を含みます。
このうち pattern 以外の三つは文字列以外にも適応できるのですが、意味合いが変わってくるので後日改めて書きます。
はっきり言って、簡単です。一つ理解すればほぼ理解できます。
というわけで簡単なサンプルだけ・・・

<xsd:simpleType name="TestType">
   <xsd:restriction base="xsd:int">
   <xsd:minInclusive value="-100" />
   <xsd:maxInclusive value="100" />
   </xsd:restriction>
</xsd:simpleType>

-100 から 100 までの整数値だけを許可するデータ型の定義です。
と、使い方は簡単なのですが、正規表現を利用する pattern 制約ファセットはかなり強力で特殊なため、次回もうちょっと詳しくメモりましょ。

XML におけるコメントの記述位置

THREE-ONE — Sun, 20 May 2007 12:23:00 GMT

XML におけるコメントの書き方って、こうしている方がほとんどじゃないですか？

<appSettings>
    <!-- ログ保存先ディレクトリ設定 -->
    <add key="logDir" value="C:\log"/>
</appSettings>

私は定期的に XML におけるコメントの書き方ってこれでいいのかと？頭をよぎることがあります。
プログラミング言語において、コメントは 100% 人のためのものです。
しかし XML において、コメントはコメントノードという立派なひとつの構成要素であり、処理系から操作することができます。
処理系から操作できるということは、システムのためにコメントを書くのもアリだということです。
そして、コメントはほとんどの場合、どれかの要素の子要素です。（コメントはルート要素の外にも記述できます）
つまり、構造的にも関連を持たせるためには子要素にするのがよいのじゃないか？と思うのです。
要するに、上記の例で言うと下記のようにということですね。

<appSettings>
    <add key="logDir" value="C:\log">
        <!-- ログ保存先ディレクトリ設定 -->
    </add>
</appSettings>

実際に、XML Schema には xsd:annotation という、XML Schema の各定義に対する注釈を記述するための要素があり、子要素に xsd:documentation と xsd:appinfo を持ちます。
xsd:documentation はスキーマ文書の読者、つまり人のための注釈を記述し、xsd:appinfo にはスキーマを処理するアプリケーションのための注釈を記述します。
対象の定義と関連を持つ必要があるため、定義の子要素として記述しなければなりません。
ちなみに、xsd:schema 以外の定義に対しては、最初の子要素である必要があります。
もちろん注釈＝コメントではありません。コメントの一部とみなすことはできると思いますが。

しかし、設定ファイルのようなファイルの場合、XSLT・XPath・DOM 等を利用して定義内容を一覧にしたい場合は無いですか？
そんな時、設定にたいするコメントを一緒に記載したくないですか？
コメントを子要素にしておけば、そんな場合に対するコーディングが非常に素直なものになります。（特に XSLT）

決して、常にコメントをこう書くべきだというつもりはありません。

人から見ると、読みにくい（その他の書式にない形式なため、なれてない）
ネストが必要以上に深くなる
全体的に冗長になる

のように、デメリットも多々あります。
私も定期的に頭をよぎる割には、そのたび色々考えて、ほとんどの場合前者を採用してしまいます。
設定ファイルのように、他人に見せるファイルならなおさらです。
見てのとおり、デメリットは「人が見たとき」という面に集中しています。
しかし、システムが扱う場合は、このデメリットはほとんど意味がないでしょう。そして前述したメリットが生きてくる場合があります。
つまり、何らかの処理系で扱う XML の場合、処理内容によっては後者の方がいい場合もあるんじゃねーの？ってことですな

空要素の定義

THREE-ONE — Tue, 01 May 2007 21:30:00 GMT

制約ファセットやるとかいっててウソばっかりです。
空要素の定義について書いておくの忘れてました。

<xsd:complexType/>

これだけです。
なぜ simpleType ではありません。complexType です。
属性を持つ場合は、

<xsd:complexType>
    <xsd:attribute name="attr"type="xsd:string"/>
</xsd:complexType>

簡単ですね。

で、これ以外にも定義する方法があります。
空要素を定義するのではなく、空要素を許可するという定義があります。
前述の定義では、例えば br 要素や img 要素のように、絶対に中身を持たない要素を定義することになります。
内容があれば記述し、なければ空要素としたいということは往々にしてありますよね。
そんな場合は、このように記述します。

<xsd:element name="要素" type="要素型" nillable="true"/>

これだけではダメなのです。 XML インスタンスにその要素に対して、xsi:nil="true" 属性を追加しなければなりません。

<要素 xsi:nil="true"/>

こんな感じです。
xsi とは XML Schema において XML インスタンス用に定義された名前空間です。
名前空間 URI は http://www.w3.org/2001/XMLSchema-instance です。
nil と nillable です。null ではありません。
nil は l が 1 本、nillable は l が 2 本繋がるところも注意です。
Ruby、Delphi なんかをやったことがある方にはおなじみかもしれませんね。

んで、ぶっちゃけめんどくさくないですか？nillable だけでいーやんって私は思うのですが。
XML インスタンスがスキーマを知っている必要があるか？ということなんですね。
「XML インスタンスを作るアプリやシステムが」ではありません。「XML インスタンスそのものが」ということです。
出力するのはたかがひとつの属性です。
ですが、検証時には

nillable で定義されているか？
xsi:nil="true" 属性がついているか？
xsi の名前空間は正しいか？

を検証しなければなりません。めんどーだと思うんだけどなぁ。

VB だとこんなことができるらしい

THREE-ONE — Sun, 22 Apr 2007 21:26:00 GMT

ヘルプみてたらこんなサンプルがあった。

Dim contactDoc As XDocument = _
<?xml version="1.0"?>
<contact>
    <name>Patrick Hines</name>
    <phone type="home">206-555-0144</phone>
    <phone type="work">425-555-0145</phone>
</contact>

Dim contact As XElement = _
<contact>
    <name>Patrick Hines</name>
    <phone type="home">206-555-0144</phone>
    <phone type="work">425-555-0145</phone>
</contact>

VB だとソース内に直接 XML を書いてインスタンスを作れるのか。
それからこんなのもあった

' Initialize the objects.
Dim phoneNumbers2 As Phone() = { _
    New Phone("home", "206-555-0144"), _
    New Phone("work", "425-555-0145")}

' Convert the data contained in phoneNumbers2 to XML.
Dim contact2 As XElement = _
    <contact>
        <name>Patrick Hines</name>
        <%= From p In phoneNumbers2 _
            Return <phone type=<%= p.Type %>><%= p.Number %></phone> _
        %>
    </contact>
Console.WriteLine(contact2)

いや、まあなんというか・・・・うーむ
ASP.NET を見てるみたいだ。
作成される XML がどんなものになるのか？ってのは直感的にわかるような気はするな。

Dim lbl As Label = _
    <asp:Label id="lbl" runat="server" cssClass="labelStyle">hoge</asp:Label>

ひょっとしてこんなことできたりするのか？？？
さすがにないかなｗ

XDocument と XmlDocument はどちらがパフォーマンスが良いか？

THREE-ONE — Sun, 22 Apr 2007 20:47:00 GMT

というわけで試してみましょう。
ソースはこちら↓

public void DoTest() {
    this.CreateDocumentWithXmlDocument();
    this.CreateDocumentWithXDocument();
}

private void CreateDocumentWithXmlDocument() {
    Stopwatch sw = new Stopwatch();
    sw.Start();
    XmlImplementation impl = new XmlImplementation();
    XmlDocument doc = impl.CreateDocument();
    XmlElement root = doc.CreateElement("root");
    doc.AppendChild(root);
    for (int i = 0; i < 10000; i++) {
        XmlElement item = doc.CreateElement(string.Format("要素_{0:0000}", i));
        XmlAttribute attr = doc.CreateAttribute(string.Format("属性_{0:0000}", i));
        attr.Value = string.Format("属性値_{0:0000}", i);
        item.Attributes.Append(attr);
        XmlText text = doc.CreateTextNode(string.Format("要素内容_{0:0000}", i));
        item.AppendChild(text);
        root.AppendChild(item);
    }
    sw.Start();
    Console.WriteLine("With XmlDocument : {0}", sw.ElapsedTicks);
    doc.Save(@"D:\temp\XmlDocument.xml");
}

private void CreateDocumentWithXDocument() {
    Stopwatch sw = new Stopwatch();
    sw.Start();
    XDocument doc = new XDocument();
    XElement root = new XElement("root");
    doc.Add(root);
    for (int i = 0; i < 10000; i++) {
        XElement item = new XElement(string.Format("要素_{0:0000}", i));
        item.Value = string.Format("要素内容_{0:0000}", i);
        XAttribute attr =
            new XAttribute(string.Format("属性_{0:0000}", i), string.Format("属性値_{0:0000}", i));
        item.Add(attr);
        root.Add(item);
    }
    sw.Start();
    Console.WriteLine("With XDocument   : {0}", sw.ElapsedTicks);
    doc.Save(@"D:\temp\XDocument.xml");
}

んで、結果がコレ(三回分)
・With XmlDocument : 467673, 460969, 470390
・With XDocument : 546143, 579681, 589850
わずかながら、XmlDocument のほうがパフォーマンスいいですね。
まあ、10000回ループさせてこれなら XDocument での XML 生成も全然アリでしょう。
ちなみに XDocument は自動的に XML 宣言を追加してくれました。

LINQ と XQuery

THREE-ONE — Sun, 22 Apr 2007 11:01:00 GMT

<?xml version="1.0" encoding="UTF-8"?>
<root>
    <item key="11">1-1</item>
    <item key="12">1-2</item>
    <item key="13">1-3</item>
    <item key="21">2-1</item>
    <item key="22">2-2</item>
    <item key="23">2-3</item>
    <item key="31">3-1</item>
    <item key="32">3-2</item>
    <item key="33">3-3</item>
</root>

コレに対して、key の値が 20 台のものを LINQ で取得してみましょう。

XDocument doc = XDocument.Load(@"D:\temp\test.xml");
XElement documentElement = (XElement)doc.FirstNode;
IEnumerable<XElement> elements =
    from item in documentElement.Elements("item")
    let keyValue = int.Parse(item.Attribute("key").Value)
    where (20 < keyValue) && (keyValue < 30)
    select item;

同じことを XQuery でやってみます。

<hoge>
{
    FOR $item IN document("test.xml")//item
    LET $key := $item/@key
    WHERE $key > 20 AND $key < 30
    RETURN $item
}
</hoge>

そっくりだと思いません？
for と from、return と select が異なりますが、かなり似てます。
これはうれしいですね。

from より for のほうがよかったなぁ。from in ってなんか違和感があるわぁ

# XQuery については、そのうち(XML Schema が終わったらかな)この blog でも書いていくつもりです

LINQ と XPath

THREE-ONE — Sun, 22 Apr 2007 10:41:00 GMT

さて LINQ の式にスポットを当ててみましょう。
Elements メソッドは子要素の IEnumerable<XElement> を取得します。
引数に XName を渡すと、指定のの名前の要素のみ列挙します。
もっと複雑な取得方法もできます。
たとえばこんな XML に対して同じことをしてみましょう。

<?xml version="1.0" encoding="UTF-8"?>
<root>
    <child>
        <item key="11">1-1</item>
        <item key="12">1-2</item>
        <item key="13">1-3</item>
    </child>
    <child>
        <item key="21">2-1</item>
        <item key="22">2-2</item>
        <item key="23">2-3</item>
    </child>
    <child>
        <item key="31">3-1</item>
        <item key="32">3-2</item>
        <item key="33">3-3</item>
    </child>
</root>

Elements メソッドを使うとこうなります。

IEnumerable<XElement> elements =
    from child in documentElement.Elements()
    from item in documentElement.Elements()
    where item.Attribute("key").Value.EndsWith("1")
    select item;

ところが DescendantsAndSelf というメソッドがありまして、これを使うと下記の様にできます。

IEnumerable<XElement> elements =
    from item in documentElement.DescendantsAndSelf("item")
    where item.Attribute("key").Value.EndsWith("1")
    select item;

ピンと来た方もいらっしゃるでしょう。
XPath には軸という概念があります。
で、この軸ごとにメソッドがあるみたいです。
ざっと列挙すると

メソッド	軸
Elements	child
Attributes	attribute
Ancestors	ancestor
AncestorsAndSelf	ancestor-or-self
Descendants	descendant
DescendantsAndSelf	descendant-or-self
NodesAfterSelf	following-sibiling
NodesBeforeSelf	preceding-sibiling

こんな感じかなぁ、全部の軸はなさげですね。(following とかは親を取得してやれってことかな？）
軸名とメソッド名がリンクしていないのが惜しいです・・・・