<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
   <channel>
      <title>XMLノート：コラム</title>
      <link>http://www.infoteria.com/jp/xmlnote/column/</link>
      <description></description>
      <language>ja</language>
      <copyright>Copyright 2008</copyright>
      <lastBuildDate>Thu, 25 Nov 2004 13:00:00 +0900</lastBuildDate>
      <generator>http://www.sixapart.com/movabletype/?v=3.34</generator>
      <docs>http://blogs.law.harvard.edu/tech/rss</docs> 

            <item>
         <title>第７回『連載の最後に --標準仕様の隙間--』</title>
         <description>これまで6回にわたってXMLのトリビアをお届けして参りましたが、ご参考になりましたでしょうか。

第６回 『XMLメディアタイプ』 (2004/10/28)
第５回 『XML文書の空白処理』 (2004/09/30)
第４回 『DOMと名前空間 』 (2004/09/02)
第３回 『名前空間と要素値、属性値 』 (2004/08/05)
第２回 『 standalone=&quot;yes&quot; ／ &quot;no&quot; 』 (2004/07/15)
第１回 『要素内容と混合内容』 (2004/06/17)

XMLは仕様の上に成り立つ標準技術です。仕様の初版では曖昧性や解釈の違いなどもあるかも知れませんが、仕様書自体も版を重ねていますし、前回のWS-IのBasic ProfileのようにSOAP 1.1やWSDL 1.1の曖昧性を補う役割の文書もあります。公開された標準技術は誰もがいつでも使える安心感があります。仕様に曖昧性などがあったとすれば、それを実装する人、使用する人が上手にケアすることによって、標準技術のメリットを大いに享受したいものです。

今回は連載の最終回ということで私自身が仕事のかたわらで、標準仕様の隙間をどうやって頭の中で整理して埋めていったかをご参考までにご紹介したいと思います。

実はコラムでお届けした内容は、ほとんどのものが、XML教育に携わっている間の皆さんからの質問がベースになっています。これまでさまざまな質問がありましたが、それに回答するべくいろいろ調べていくうち自分の中でもだんだん内容が整理されてきて、今回ある程度まとまった形でお届けすることができました。

質問をいただいたときにはその都度調べながら回答していくわけですが、その後ふと考えてみると、さらにこういう場合はどうなんだろうといった、また新しい疑問が自分の中に生まれてくることはよくあります。そのとき時間があれば調べてみればよいのですが、なかなかそうもいきません。そんなときはとりあえずメモに残しておき、解決を先延ばしにします。知りたい内容をピンポイントで探してもすぐに見つかる確率は小さいですが、その後の作業の合間にその知りたいことに遭遇する確率は大きいからです。つまり時間が解決してくれることは多いです。あとはまとまった時間がとれたときに、メモに残した疑問点を集中的に解決するのも効果的です。

またさらに、この連載コラムを書いたことも自分自身の勉強になりました。勉強というより、頭の中をすっきりと整理させることができました。知っているつもりでも文章にまとめるとなると、またまた新しい疑問が出てくることもしばしばです。今回ばかりは毎回の締め切りがありますので、先延ばしというわけにはいきませんが。。</description>
         <link>http://www.infoteria.com/jp/xmlnote/column/doc/xml_point_xml_041125.html</link>
         <guid>http://www.infoteria.com/jp/xmlnote/column/doc/xml_point_xml_041125.html</guid>
         <category>xml_point</category>
         <pubDate>Thu, 25 Nov 2004 13:00:00 +0900</pubDate>
      </item>
            <item>
         <title>第６回 『XMLメディアタイプ』</title>
         <description></description>
         <link>http://www.infoteria.com/jp/xmlnote/column/doc/xml_point_mediatype_041028.html</link>
         <guid>http://www.infoteria.com/jp/xmlnote/column/doc/xml_point_mediatype_041028.html</guid>
         <category>xml_point</category>
         <pubDate>Thu, 28 Oct 2004 13:00:00 +0900</pubDate>
      </item>
            <item>
         <title>XMLマスター - 「取得したい資格」第１位の理由は?</title>
         <description><![CDATA[<img src="/jp/xmlnote/column/img/xmlmaster1.gif" align="right" />　<a href="http://jibun.atmarkit.co.jp/" target="_blank">＠IT自分戦略研究所</a>の調査で、XMLマスターが2002年から3年連続で「エンジニアが取得したい資格」のベンダーニュートラル資格部門の第１位に選ばれた。この調査は、<a href="http://jibun.atmarkit.co.jp/" target="_blank">＠IT自分戦略研究所</a>が読者を対象に毎年行っているアンケートであり、今年はこの8月に実施され914名の回答を得ている。資格に関する調査は、国家/公的資格、ベンダーニュートラル資格、ベンダー資格に分けられており、XMLマスターの取得意向はベンダーニュートラル部門でUML、Linux、PMPなどの他の資格を引き離して圧倒的な１位である（図１）。]]></description>
         <link>http://www.infoteria.com/jp/xmlnote/column/doc/xml_column_xmlmaster_041014.html</link>
         <guid>http://www.infoteria.com/jp/xmlnote/column/doc/xml_column_xmlmaster_041014.html</guid>
         <category>xml_column</category>
         <pubDate>Thu, 14 Oct 2004 13:00:00 +0900</pubDate>
      </item>
            <item>
         <title>EAI  - 企業アプリケーション統合に求められる条件は?</title>
         <description>　最近EAIというキーワードをよく聞くようになった。正確にいうと「再び」よく聞くようになった。EAIはEnterprise Application Integrationの略であり、1998年前後にも一度ITの注目キーワードとして登場している。IT業界では単に読んだだけでは意味がよくわからない3文字略語が多い中で、EAIは比較的ストレートな用語であり、直訳しても「企業アプリケーション統合」とわかりやすい。具体的には、企業内で業務に使用される複数のシステムを連携させ、データやプロセスの効率的な統合を図るソフトウェアやその仕組みを指す。そのEAIが、なぜ再度注目を集めているのか? 以前話題になったときと何が違うのだろか?</description>
         <link>http://www.infoteria.com/jp/xmlnote/column/doc/xml_column_eai_040930.html</link>
         <guid>http://www.infoteria.com/jp/xmlnote/column/doc/xml_column_eai_040930.html</guid>
         <category>xml_column</category>
         <pubDate>Thu, 30 Sep 2004 13:00:00 +0900</pubDate>
      </item>
            <item>
         <title>第５回 『XML文書の空白処理』</title>
         <description><![CDATA[<p>XML文書に、改行やインデントなどの無意味な空白が含まれる場合があります。たとえば次のXML文書では2箇所に含まれています。＜root＞開始タグと＜value＞開始タグの間の空白と、＜/value＞終了タグと＜/root＞終了タグの間の空白です。</p>
<p>
＜root＞<br>
  ＜value＞50＜/value＞<br>
＜/root＞
<br></p>

<p>この2箇所の空白は見た感じ無意味だと思われますが、XMLを処理するパーサーがこれらの空白をどう扱うかは、特定のルールに従います。</p>

<p>●SAX<br>
================================================<br>
SAXパーサーは、無意味だと判断できる場合にその空白をignorableWhitespaceメソッドの方へ送り、そうでない場合にはその空白をcharactersメソッドに送ります。<br>

無意味だと判断できる場合とは、XML文書に文書型宣言があり、DTDの要素型宣言が要素内容（element content）として宣言（この場合ならたとえば、＜!ELEMENT root (value*)＞）され、なおかつSAXパーサーがこれを構文解析した場合です。当然ながら妥当性の検証を行う場合には、必ず構文解析します。しかしそうでない場合にSAXパーサーが要素型宣言を構文解析するかしないかは、パーサー次第です。<br></p>

<p>●DOM<br>
================================================<br>
DOM Level 2まででは、XML文書の読み込みと妥当性の検証についての仕様が定められていませんでしたので、XML文書の読み込み時に無意味な空白をどう扱うかについては明確に定められていませんでした。実際、Apache Xercesはデフォルトですべての空白を読み込み、Microsoft社の.NETのXMLパーサーはデフォルトでは無意味な空白を読み込みません。<br>
ところがDOM Level 3では、XML文書の読み込み時にすべての空白をデフォルトで読み込むよう定められました。もちろんこれは既定値ですので、設定（ここではプロパティとよびます）により変更することができます。.NETのパーサーはこれに相当するプロパティ（これはMicrosoftの拡張機能であり、DOM Level3仕様とイコールではない）を実装していますので、DOM Level 3との違いには注意したいところです。<br>
今後DOM Level 3を実装するパーサーを扱う場合には、無意味な空白の読み込み方法を、明示的に設定した方がよいかもしれません。<br></p>]]></description>
         <link>http://www.infoteria.com/jp/xmlnote/column/doc/xml_point_xml_040930.html</link>
         <guid>http://www.infoteria.com/jp/xmlnote/column/doc/xml_point_xml_040930.html</guid>
         <category>xml_point</category>
         <pubDate>Thu, 30 Sep 2004 12:00:00 +0900</pubDate>
      </item>
            <item>
         <title>第４回 『 DOMと名前空間 』</title>
         <description>XMLを処理するプログラミングとしてDOMプログラミングを使用する方も多いのではないでしょうか。今回のコラムでは、DOMと名前空間について考察してみます。

DOMの仕様（Core）はLevel 1,2,3が勧告されています。

Level 1の勧告は名前空間仕様の勧告より前でしたので、Level 1ではXML名前空間に対応していません。そしてLevel 2で名前空間を伴った処理を行うことが可能になりました。Level 2では???NSといった名前のいくつかのメソッドが導入され、Level 1メソッドが名前空間に対応しました。たとえばsetAttributeメソッドとsetAttributeNSメソッドはどちらも属性を追加（または更新）できますが、名前空間を伴った処理では必ずsetAttributeNSを使用します。そもそもLevel 1では名前空間の概念が導入されていませんので、Level 1のどのメソッドも、名前空間を適切に処理できることを期待することはできません。

Level 2で名前空間を伴った処理を行うことが可能になったわけですが、Level 2ではXML文書へのシリアライズの方法が定められていませんので、この点で実装依存となります。たとえばApache Xerces2-J（2.6.2）でプログラミングし、＜root/＞のroot要素に対してsetAttributeNS(&quot;urn:aaa&quot;,&quot;a:att&quot;,&quot;value&quot;)を実行し、XML文書として出力させると結果は＜root a:att=&quot;value&quot;/＞となります。a接頭辞の名前空間宣言がありませんので名前空間仕様に違反していますが、これはシリアライズ時に名前空間宣言の解決が行われなかっただけであって、メソッドの実行自体がおかしかったわけではありません。シリアライズ直前の、DOMツリー上でのatt属性の名前空間を調べてみると、確かに&quot;urn:aaa&quot;です。（DOMプログラミングでatt属性のnamespaceURIアトリビュートを調べてみると分かります。）

Level 3ではDOMツリーをXML文書としてシリアライズする方法を定めましたので、この問題点も解決されました。特にLevel 3 Core仕様書のAppendix B（Namespaces Algorithms）では、名前空間宣言を解決するアルゴリズムが定められています。これに従って上記の結果をシリアライズすると、結果は＜root a:att=&quot;value&quot; xmlns:a=&quot;urn:aaa&quot;/＞となります。

今後このLevel 3が広く実装されると、標準的なシリアライズ結果を予測でき、DOMプログラミングにおいて名前空間宣言を意識する必要がなくなります。</description>
         <link>http://www.infoteria.com/jp/xmlnote/column/doc/xml_point_dom_040902.html</link>
         <guid>http://www.infoteria.com/jp/xmlnote/column/doc/xml_point_dom_040902.html</guid>
         <category>xml_point</category>
         <pubDate>Thu, 02 Sep 2004 11:56:05 +0900</pubDate>
      </item>
            <item>
         <title>XBRL - 企業財務情報の世界標準を知る</title>
         <description><![CDATA[<img src="http://www.infoteria.com/jp/xmlnote/column/img/xbrllogo.gif" border="0" align="right" />　インターネットの普及や電子政府の進展に伴い、企業情報を再利用可能な電子データとして流通させる必要性が高まってきている。その企業情報の中でも最も重要な情報が財務関係の情報であり、その標準仕様として「XBRL」(eXtensible Business Reporting Language)が注目され世界的に普及が進んでいる。今回は、このXBRLとはどのようなものか概要を解説しよう。]]></description>
         <link>http://www.infoteria.com/jp/xmlnote/column/doc/xml_column_xbrl_040901.html</link>
         <guid>http://www.infoteria.com/jp/xmlnote/column/doc/xml_column_xbrl_040901.html</guid>
         <category>xml_column</category>
         <pubDate>Wed, 01 Sep 2004 13:00:00 +0900</pubDate>
      </item>
            <item>
         <title>第３回 『 名前空間と要素値、属性値 』</title>
         <description>XMLの名前空間仕様（Namespaces in XML）では、要素と属性の名前空間を定義するための仕組みを定めています。要素や属性自体の名前空間であって、要素値や属性値については一切触れていません。ところがいくつかのXMLの応用仕様では、名前空間が、要素値や属性値にまで有効となるように名前空間を応用しています。

ここではXML Schema、XPath、SOAPを例に、それぞれによる名前空間の有効範囲を見てみますが、これらの名前空間の応用は、各応用仕様（XML Schemaなど）でそれぞれが定めるものですので、その有効範囲（名前空間仕様以上の有効範囲）はまちまちです。

●XML Schema
====================
XML Schemaのelement要素やattribute要素では、type属性を記述することによって、その要素または属性の型を指定します。たとえば次のような例です。

＜xsd:schema xmlns:xsd=&quot;http://www.w3.org/2001/XMLSchema&quot;＞
  ＜xsd:element name=&quot;price&quot; type=&quot;xsd:nonNegativeInteger&quot; /＞
　　　・・・
ここで「nonNegativeInteger」はXML Schemaで定められている組み込み型を表し、「負でない整数」と定義されているものです。XML Schemaで定められている型ですので、XML Schema名前空間を表す接頭辞（ここではxsd）とともに記述されます。

前述の例を、デフォルトの名前空間を使用し記述しなおすと次のようになります。

＜schema xmlns=&quot;http://www.w3.org/2001/XMLSchema&quot;＞
  ＜element name=&quot;price&quot; type=&quot;nonNegativeInteger&quot; /＞
　　　・・・
XML Schemaの構文となるschema要素やelement要素の名前空間接頭辞が不要になる（名前空間仕様にもとづくもの）とともに、type属性値の名前空間接頭辞もなくなります（XML Schemaで定める名前空間の応用）。

XML Schemaのelement要素やattribute要素では、ref属性を記述することによって、グローバルに宣言されたelement要素やattribute要素を参照することができますが、ref属性の属性値も同様です。

●XPath
====================
XPathはXSLTなどで使用されますが、このときXPathは、XSLTの属性値の部分に記述されます。このときXPathの名前空間は、XSLTの名前空間宣言を使用します。

次のような例です。

＜xsl:stylesheet version=&quot;1.0&quot;
      xmlns:xsl=&quot;http://www.w3.org/1999/XSL/Transform&quot;
      xmlns:aaa=&quot;urn:infoteria:column:aaa&quot;＞
＜xsl:template match=&quot;/&quot;＞
  ＜xsl:apply-templates select=&quot;aaa:record&quot; /＞
　　　・・・
この場合のselect属性は、&quot;urn:infoteria:column:aaa&quot;名前空間のrecord要素を選択します。

XPathはXML Schemaと異なり、デフォルトの名前空間を使用しないと定められていますので、次の例では&quot;urn:infoteria:column:aaa&quot;名前空間のrecord要素を選択することができません。

＜xsl:stylesheet version=&quot;1.0&quot;
      xmlns:xsl=&quot;http://www.w3.org/1999/XSL/Transform&quot;
      xmlns=&quot;urn:infoteria:column:aaa&quot;＞
＜xsl:template match=&quot;/&quot;＞
  ＜xsl:apply-templates select=&quot;record&quot; /＞
　　　・・・

この場合のselect属性は、名前空間なしのrecord要素を選択します。

●SOAP
====================
SOAPでは、SOAPメッセージの処理に何らかのエラーがあった場合にフォルトコードを返却するよう定めており、そのフォルトコードはSOAP名前空間に属する値です。次のような例です。

＜SOAP-ENV:Envelope
  xmlns:SOAP-ENV=&quot;http://schemas.xmlsoap.org/soap/envelope/&quot;＞
   ＜SOAP-ENV:Body＞
       ＜SOAP-ENV:Fault＞
           ＜faultcode＞SOAP-ENV:Server＜/faultcode＞
　　　・・・

SOAP 1.1仕様の中ではデフォルトの名前空間には一切触れていませんので、このように、必ず名前空間接頭辞とともに記述します。

※注：コード記述内の＜＞については、本来半角の&lt;&gt;となります。</description>
         <link>http://www.infoteria.com/jp/xmlnote/column/doc/xml_point_namespaces_040805.html</link>
         <guid>http://www.infoteria.com/jp/xmlnote/column/doc/xml_point_namespaces_040805.html</guid>
         <category>xml_point</category>
         <pubDate>Thu, 05 Aug 2004 13:00:00 +0900</pubDate>
      </item>
            <item>
         <title>次世代Webフォーム「XForms」</title>
         <description>　XML関連で最近注目を浴びてきている技術のひとつにXFormsというフォームを中心としたユーザーインターフェイス構築技術がある。XFormsは、W3Cにおいて「The Next Generation of Web Forms」とも呼ばれ、現在広く普及しているHTMLのフォームの次世代版である。まず、その特徴を見てみよう。</description>
         <link>http://www.infoteria.com/jp/xmlnote/column/doc/xml_column_xforms_040727.html</link>
         <guid>http://www.infoteria.com/jp/xmlnote/column/doc/xml_column_xforms_040727.html</guid>
         <category>xml_column</category>
         <pubDate>Tue, 27 Jul 2004 12:00:00 +0900</pubDate>
      </item>
            <item>
         <title>第２回 『 standalone=&quot;yes&quot; ／ &quot;no&quot; 』</title>
         <description><![CDATA[XMLは、DTDを用いて妥当性の検証を行うことができます。XML文書に文書型宣言（<!DOCTYPE・・・>）を記述し、XMLプロセッサで妥当性の検証を行います。

妥当性の検証を行う場合XMLプロセッサは、XML文書と、内部・外部を問わずすべてのDTDを読み込むことによって妥当性の検証を行います。

妥当性の検証を行わないXMLプロセッサ（非検証XMLプロセッサ）がDTDを全く読み込まないというのは誤りで、一部のDTDを読み込むことが義務付けられています。一部とは、パラメータ実体を除いた内部サブセットDTDです。非検証XMLプロセッサは、（内部・外部を問わない）パラメータ実体と外部サブセットDTD（ここではこれらを外部リソースと呼びます）を読み込んでもよいし、読み込まなくても構いません。

それでは非検証XMLプロセッサは、一部またはすべてのDTDを読み込んで何をするのでしょうか。それは実体宣言により内部実体を解決し、属性リスト宣言から属性の型を読み取り（属性値の正規化に影響します）、またデフォルトの属性値を与えます。

このようなXMLインスタンスに影響を与えるDTDの宣言が、外部リソースに出現しないことを意図的に宣言できるのが、XML宣言部に記述する「standalone="yes"」です。これによりXMLインスタンスを処理する際に、妥当性の検証を行わないのであれば外部リソースを無視できるといったメリットが生まれます。

ところが実際に外部リソースにそのような宣言がない場合であっても、「standalone="yes"」と記述し、そして外部サブセットDTDにより妥当性の検証を行った場合、ひとつ厄介な問題があります。それは次のような妥当性制約が定義されている点です。

◆定義されている妥当性制約
外部リソースで要素内容（子要素のみを含み文字データを含まない）として宣言されている要素が空白文字を含んでいる場合は「standalone="no"」でなくてはならない

つまり「standalone="yes"」と記述した場合、XMLインスタンスにインデントなどの無意味な空白が含まれた場合は、その点で妥当性検証エラーとなってしまいます。XMLのシリアライズの方法によってはインデントなどが含まれる場合もあり、完全に無意味な空白を排除できないような場合は上記の点が問題となります。

結局この件に関する結論としては、妥当性の検証を必要としないなら、「standalone="yes"」が理想であるが、妥当性の検証を必要とするなら「standalone="no"」が現実的である、といったことになりそうです。]]></description>
         <link>http://www.infoteria.com/jp/xmlnote/column/doc/xml_point_dtd_040715.html</link>
         <guid>http://www.infoteria.com/jp/xmlnote/column/doc/xml_point_dtd_040715.html</guid>
         <category>xml_point</category>
         <pubDate>Thu, 15 Jul 2004 00:00:00 +0900</pubDate>
      </item>
            <item>
         <title>第１回 『要素内容と混合内容』</title>
         <description><![CDATA[<p>はじめまして。インフォテリア教育部の木村です。</p>
<p>私はこれまで教育という立場でXMLに携わってきましたが、XMLには実はちょっと紛らわしい部分があったり、あるいは直感では誤解してしまいそうな部分があることにいくつか気が付きました。この連載コラムでは、XMLのそのような話題を7回にわたって解説してみたいと思います。</p>
<p>まずは手始めに、「要素内容と混合内容」についてです。<br>
DTDでは、ある要素に対する子要素の存在回数などを定義するわけですが、このとき、ある要素の内容として実際考えられるパターンは次の3つです。</p>
<blockquote>
<p><b>◆ある要素の内容として実際考えられる３つのパターン</b><br>
(1) 子要素のみを内容とする<br>
(2) 文字データのみを内容とする<br>
(3) 子要素と文字データを内容とする
</p>
</blockquote>
<p>このときXML 1.0ではこの3つのパターンを2つに分けて、それを要素内容（element content）と混合内容（mixed content）と定義しています。(3)が子要素と文字データの双方を含んでいますので、感覚的には混合内容が(3)のみを指しているように感じますが、実は(1)が要素内容で、(2)(3)が混合内容です。(2)は、子要素の出現が０回である混合内容です。</p>
<p>(2)を混合内容として認識していなくても実際困ることはないと思いますが、「要素内容」という言葉が、XML 1.0の中で定義されている特別な言葉であることを知っていると、それだけXMLの理解が早まります。</p>
<p>ある文章の中で「element content」や「要素内容」（あるいは「エレメントコンテント」などの和訳）という言葉を見たときに、これが単なる要素の内容を指している一般用語ではなく「子要素のみを含み、文字データを含まない」ことが前提になっているということがすぐにイメージできるとよいと思います。</p>
<p>特に要素に含まれる無意味な空白について言及する場合など、XML 1.0はもちろん、DOMやSAXやXML Information Setなどの仕様書内に出てきますので、今度注意してみてください。</p>]]></description>
         <link>http://www.infoteria.com/jp/xmlnote/column/doc/xml_point_element_040617.html</link>
         <guid>http://www.infoteria.com/jp/xmlnote/column/doc/xml_point_element_040617.html</guid>
         <category>xml_point</category>
         <pubDate>Thu, 17 Jun 2004 00:00:00 +0900</pubDate>
      </item>
            <item>
         <title>話題のBlogとXMLの関係</title>
         <description><![CDATA[　最近インターネットで「Blog」が急速に普及している。「Blog」とは、Web Logを略したもので、もともとはWeb上のログつまり記録を残す、日記的なものに使われていたものだ。それだけなら、従来からあるCMS (Content Management System)を使えばよいのだが、Blogがここまで普及した背景には、他のWebサイトやサービスとの連携の強さがある。そして、実はそこでXMLが活用されている。

<div class="title2">国内で急速に普及が進む</div>

　Blogは米国では2002年頃から流行し始めたが、日本国内ではここにきて急速に普及が進んでいる。その背景には、大手ISPがこぞってBlogのASPサービスを始めたということがある（<a href="#table1">表１：大手ISPのブログサービス</a>）。さらに、Blogツール開発の大手Six Apart社(MovableTypeの開発元、本社米国)が3月18日に<a href="http://www.sixapart.jp/" target="_blank">日本法人</a>を設立するなどBlog関連サービス側の動きが慌しくなっている。

<table align="right" border="0"><tr><td><font size="-2" color="#000066"><b>図１：週刊！木村剛</b></font></td></tr><tr><td><a href="http://kimuratakeshi.cocolog-nifty.com/" target="_blank"><img src="http://hirano.com/blog/images/column11-1.gif" border="0" align="right" /></a></td></tr><tr><td><br /><font size="-2" color="#000066"><b>図２：ふじすえBlog</b></font></td></tr><tr><td><a href="http://fujisue.net/blog/index.html" target="_blank"><img src="http://hirano.com/blog/images/column11-2.gif" border="0" align="right" /></a></td></tr></table>コンテンツ側も、単に一個人の日記ではなく、双方向コミュニケーションツールとしての利用やオフィシャルな情報発信ツールとしての利用が活発化している。

　例えば、エコノミストの木村剛氏は、Blogで「週刊！木村剛」(<a href="http://kimuratakeshi.cocolog-nifty.com/" target="_blank">http://kimuratakeshi.cocolog-nifty.com/</a>)を発行し、読者と毎日のようにインタラクティブな議論を展開している。民主党の藤末健三氏は「ふじすえBlog」(<a href="http://fujisue.net/blog/index.html" target="_blank">http://fujisue.net/blog/index.html</a>)で、毎日のように全国各地での講演や政策について自ら直接発信し、有権者との意見交換を行っている。米国では大統領選にまでBlogが活用されるようになっているが、国内でもこのように実際の政治・経済の現場でBlogが使われ始めている。さらに、まだ数は少ないが国内企業の公式サイトでの導入も始まっている（このページも実はBlogだ）。

<div class="title2">BlogとXMLの関係</div>

　では、このBlogとXMLとはどのような関係があるのだろうか。Webサイトを表示するには、HTMLで十分だし、コンテンツの管理は内部的なことなので何らかの形でデータベース化しておけばよい。実は、XMLはBlogの最大の特徴である他のサイトやサービスとの連携の部分で活躍しているのである。

<div class="title3">１）RSSフィード</div>
<p> </p>
<table border="0" align="right"><tr><td><font size="-3" color="#000066"><b>図３：RSSデータ(index.xml)</b></font></td></tr><tr><td><a href="http://fujisue.net/blog/index.xml" target="_blank"><img src="http://hirano.com/blog/images/column11-3.gif" border="0" align="right" /></a></td></tr></table>　Blogには、RSS(Rich Site Summary / RDF Site Summary)フィード用のデータを提供する機能がある。RSSフィードとは、ある種のデータ提供サービスで、特定のWebサイトの読者がそのWebサイトに行かなくても更新状況や更新内容を知ることができるしくみである。そして、このデータフォーマットとしてXMLが使用されている。

　例として前出の「ふじすえblog」の例を見てみよう。このサイトのURL <a href="http://fujisue.net/blog/index.html" target="_blank">http://fujisue.net/blog/index.html</a>を表示してみてほしい。まずは、普通に画面が表示される。次に、URLの最後の「.html」を「.xml」に<a href="http://fujisue.net/blog/index.xml" target="_blank">変えて表示</a>してみてほしい。どうだろう。サイトの内容がXMLで表示されたと思う。このようにBlogサイトは、HTMLだけでなくXMLでも情報を発信しているのだ。

<table border="0" cellpadding="5" align="left"><tr><td><font size="-2" color="#000066"><b>図４：RSSフィードサービスの一例（Bloglines.com）</b></font></td></tr><tr><td><img src="http://hirano.com/blog/images/column11-4.gif" border="0" align="left" padding="5" /></td></tr></table>　XMLで送ることで、受信側はそのデータを加工して使うことができる。例えば、複数のサイトの更新状況を並べて表示したり（図4）、更新された内容だけを取り出してニュースティッカーのように画面上に流れ表示をしたりといった活用だ。

　ところで、RSSはXMLデータであるが、その仕様はまだ完全に一本化されていない。現在RSS 0.9、RSS 1.0、RSS 2.0そしてAtomという４つの仕様があるが、GoogleやMovableTypeがAtomを採用したことから、Atom仕様に大きな期待がかかってきている。

<div class="title3">２）トラックバック</div>

　トラックバックは、Blogの持つ大変ユニークな機能だ。簡単にいうと「逆リンク」の機能といえる。通常、自分とサイトと関連する情報のあるサイト（対象サイト）をリンクする場合には、自分のサイトにその対象サイトへのリンクを置く。しかし、トラックバックを使うと、「対象サイト上に自分のサイトへのリンクを自動的に置く」ことができるのである。

　このトラックバックでもXMLが活用されている。トラックバックの仕組みはこうだ。まず、自分のサイトからトラックバックしたいサイトにトラックバックのリクエストを送る。ここで送る内容は、Blog名(blog_name)、タイトル(title)、記事URL(url)、記事の概要(excerpt)である。このリクエストは、HTMLのフォームからも送ることができるように単純なHTTP POSTの形式になっている。そして、そのリクエストを受け付けたサイトは、その内容を自らのサイトに反映して、レスポンスを返す。このレスポンスがXML形式になっている。

<div class="title3">３）サイトの更新通知 (Ping)</div>
<p> </p>

<table align="right" border="0"><tr><td><font size="-2" color="#000066"><b>図５：サイト更新通知XMLの例</b></font></td><tr><tr><td><img src="http://hirano.com/blog/images/column11-5.gif" border="0" /></td></tr></table>　Blogでは、RSSのようにサイトの情報を受動的に提供するしくみだけでなく、サイトの更新を能動的に通知(Ping)するしくみがある。このしくみは、Blogサイトの情報集積サイトや検索サイトなどで使われている。例えば、米国の<a href="http://www.weblogs.com/" target="_blank">Weblogs.com</a>や、国内の<a href="http://ping.bloggers.jp/" target="_blank">Bloggers.jp</a>などがこれにあたる。そしてこの更新情報の通知にXML-RPCが使用されている（図5）。

　MovableTypeなどのBlogツールでエントリ更新をすると同時に、Blogツールからサービスサイトに通知が行われる。このプロトコルでは、Blog名 、BlogのURL、更新されたURL、カテゴリ名をXMLで通知する。そして、登録サイトから、エラー値とメッセージがXMLで返される（<a href="http://www.xmlrpc.com/weblogsCom" target="_blank">詳細仕様</a>）。

<div class="title2">さらに進化するBlogの環境</div>

　このように、Blogの特徴の多くはXMLを使って実現されている。電子商取引やSOAPによるシステム連携などの大規模なシステムだけでなく、このような草の根的な技術、サービスでもXMLが活用されるようになってきているのである。

　そしてBlogは、今でも日進月歩で進化している。スパムコメントの排除、複数Blogへのシングルログイン、Moblog（Mobile Blog = モバイル環境でのBlog）など、開発中の技術は目白押しだ。そしてこのような進化の背景でもXMLは引き続き重要な役割を果たしていくだろう。]]></description>
         <link>http://www.infoteria.com/jp/xmlnote/column/doc/xml_column_blog_040513.html</link>
         <guid>http://www.infoteria.com/jp/xmlnote/column/doc/xml_column_blog_040513.html</guid>
         <category>xml_column</category>
         <pubDate>Thu, 13 May 2004 09:00:00 +0900</pubDate>
      </item>
            <item>
         <title>Webサービス標準化の全体像と課題</title>
         <description>　XMLは1998年の誕生から6年を経て、いまやコンピュータデータの共通言語として確固たるポジションを確立し、数々の新しい技術の基盤技術ともなっている。その新技術の中でも、注目を浴びているWebサービスの標準化に着目してみよう。Webサービスは当初、SOAP、WSDL、UDDIの３つの技術で構築されるサービスがであると定義されていたが、Webサービスを繋いで実際に動かすためにはさらに多くの取り決めが必要であることから、数多くのWebサービス関連仕様の提案と標準化が進んでいる。これらの仕様は「WS-」で始まる名称をつけられることが多いため、ここではこれらをまとめて「WS-標準化」と呼ぶこととする。個別仕様の詳しい内容は専門の記事に譲るとして、ここではWebサービスを取り巻く数多くの標準化の動向を見てみよう。</description>
         <link>http://www.infoteria.com/jp/xmlnote/column/doc/xml_column_webservices_040427.html</link>
         <guid>http://www.infoteria.com/jp/xmlnote/column/doc/xml_column_webservices_040427.html</guid>
         <category>xml_column</category>
         <pubDate>Tue, 27 Apr 2004 13:00:00 +0900</pubDate>
      </item>
            <item>
         <title>第10回 　『ＸＭＬマスター世界展開と中国』</title>
         <description>こんにちは、インフォテリアの平野です。

いよいよ先月から、日本発のXMLの技術認定制度「XMLマスター」が世界121ヶ国で受験可能となりました。

121ヶ国の中でも、特にお隣の中国はXMLマスターに対して興味をお持ちの方が最も多い国です。それというのも、北京、上海、大連といった大都市を中心に日本向けのソフトウェア開発が盛んで現在でも増加傾向にあることや、日本と同様にお墨付きを重視する風潮などに起因しています。実際、XML技術者育成推進委員会理事の大手ITベンダー各社も数多くのソフトウェアを中国で開発しています。このようなことから、XMLマスターの世界展開を行う以前から「XMLマスターを中国で受験するにはどうすればよいのか」と言った問い合わせをたびたび受けていました。 

さて、XMLマスターの試験が開始されるにあたり、事務局の役割として私も年明け早々北京に渡り、IT教育会社（試験センターも兼ねる）の責任者方々を対象にXMLマスターの説明会を行ってきました。IT教育会社の興味も非常に高く、会場は満員となっていました。

説明会にはプロメトリック社の陳総経理も出席され、「これまでは、ITベンダーの技術を中心とした教育・試験が行われていたが、これからのオープン時代は、テクノロジーを中心とした教育・試験が重要となる」と挨拶され、参加した方々の大きな同意を得ていました。

また、教育会社や大学との個別の話の中では、エンジニアのソフトウェア基礎技術に対する並々ならぬ意欲を感じました。そうした個々の意欲に加えてしっかりとした教育や認定制度が整っていくことで、これから中国がコスト面だけでなく技術や能力といった側面で世界で独自の役割を担う時代もそう遠くないでしょう。

つい最近、携帯電話の加入数で中国が日本を抜いたとか、インターネットの接続数で中国が日本を抜いたとの報道がなされていますが、XMLマスターの取得者数で中国が日本を抜いたというニュースを聞く日もあるかもしれません。

しかし、もし国外の取得者の方が多くなるということが起こったとしても、日本のIT関連各社で大同団結して推進してきたXMLマスターが、グローバルな技術指標として認められるということですから、大いに喜ぶべきことでしょう。これから、中国に限らずソフトウェア開発のボーダーはどんどん下がっていきます。海外にソフトウェアの開発を委託されたり、共同開発されたりする時には、他の認定資格と同じように全世界で取得可能なXMLマスターも技術指標の一つとして是非活用してください。</description>
         <link>http://www.infoteria.com/jp/xmlnote/column/doc/xml_yomoyama_xmlmaster_040219.html</link>
         <guid>http://www.infoteria.com/jp/xmlnote/column/doc/xml_yomoyama_xmlmaster_040219.html</guid>
         <category>xml_yomoyama</category>
         <pubDate>Thu, 19 Feb 2004 00:00:00 +0900</pubDate>
      </item>
            <item>
         <title>第８回　『良いＩＴコンサルタントの見分け方』</title>
         <description><![CDATA[こんにちは、インフォテリア斎藤です。

さて今回は、このコラムの最終回になります。最終回は、お客様の視点から見た、良いＩＴコンサルタントの見分け方についてご紹介します。

結論から申し上げると『良いＩＴコンサルタントは「ＮＯ」を明確に言えるコンサルタント』です。しかし、「ＮＯ」を言って、お客様と問題を起こすコンサルタントは悪いＩＴコンサルタントです。良いＩＴコンサルタントは「ＮＯ」を言うことによって、お客様から評価され、感謝されるコンサルタントです。

お客様に「ＮＯ」を言って納得を得るためには、十分な論理と洞察、そしてお客様とのコミュニケーションが必要になります。お客様は自らの要求に対して「ＮＯ」を言われたわけですから、素直に受け入れていただける状況にはなりにくいと思います。そこで重要なことは、十分な論理と洞察による明確な理由と「お客様のため」という考え方が基盤にあることです。微塵でも、理由にぶれがあったり、お客様のためという基盤が揺らぐようなものが見えたりしたら、その「ＮＯ」は受け入れられません。

システム開発の現状において、お客様の要求に対して「ＹＥＳ」ばかりを言うコンサルタントは、プロジェクト開始当初はお客様から重宝されがちです。始めの内は和やかでも、プロジェクトが進むにつれて、お客様のためという基盤を持たないプロジェクトは雰囲気が悪くなります。えてして「ＹＥＳ」ばかりのコンサルタントが行うプロジェクトは、スケジュールが遅れがちで、次から次へと問題が発生するからです。最悪の場合、予定通りにカットオーバーできなくなり、お客様とコンサルタントの属す会社との間で訴訟問題になりかねません。

やはり、まずお客様の業務要件およびシステム要件を明確にした上で、お客様の要求に対してシステムとして「ＹＥＳ」「ＮＯ」をきちんと判断することが重要です。加えて、システムの観点から業務に対して「ＹＥＳ」「ＮＯ」を判断し、提言することができれば、お客様に提供できる価値が上がります。「ＮＯ」という判断をした場合、お客様の要求を満たすための代替案まで提案することができれば、さらに、お客様に提供できる価値が上がります。

あるソフトウェア・ベンダーのコンサルタントは、お客様に対して営業する際に、自社のソフトウェアが適していないと判断すると「貴社の要求には向きません」とはっきり言うそうです。ソフトウェアの売上機会がなくなるわけですから、営業担当者からするととんでもない話と思われますが、そうするとお客様からは「ソフトウェアはともかく、コンサルタントだけでも派遣して下さい」と言われるそうです。つまり、別の売上機会が発生することになります。会社として、このように判断することを善としていることはすばらしいことだと思います。

10年以上前には、日本のコンサルタントのプロジェクトにおける主要業務は大半が、お客様がシステムの選択などを行う際、あらかじめ担当者が決定した要求内容を社内稟議で通すため、その理由づけとして必要となる論理的な説明資料の作成でした（当然、異なるプロジェクトもたくさんありましたが…）。その要求が「ＹＥＳ」であるということを導き出すための理由を作成するために大量の調査・分析を行うというものでした。要求は「ＹＥＳ」であると決まっているわけですから「ＮＯ」を言う余地はありませんでした。その成果物が、後からは誰も読まないような分厚いレポートでした。

昨今は、お客様の要求が厳しくなり（当然とも言えるのですが…）、分厚いレポートよりも目に見える成果、具体的には、予定通りにシステム稼働をカットオーバーさせること、システム稼働による業務効率の改善、などの成果を出さなければならなくなりました。言い換えると、ＩＴコンサルタントにとって、お客様に対して成果を出すための「ＮＯ」を言うことのできる環境になってきているということです。成果を出すことのできないコンサルタントは淘汰されていくことになりますから、厳しい環境であるとも言えます。

この環境で生き残っていくために、ＩＴコンサルタントは基礎能力を備えて、お客様にサービスを提供していく中で経験を積んでいくことが、今まで以上に重要になっていくものと思います。

お客様の視点から見た良いＩＴコンサルタントの見分け方について、おわかりいただけましたでしょうか？8回にわかってコラム：「ＩＴコンサルタント」って何？？をご愛読いただきまして、ありがとうございました。本コラムに関するご意見、ご感想などございましたら、<a href="mailto:sales@infoteria.co.jp">sales@infoteria.co.jp</a> までお気軽にご連絡ください。]]></description>
         <link>http://www.infoteria.com/jp/xmlnote/column/doc/it_consultant_consultant_040205.html</link>
         <guid>http://www.infoteria.com/jp/xmlnote/column/doc/it_consultant_consultant_040205.html</guid>
         <category>it_consultant</category>
         <pubDate>Thu, 05 Feb 2004 00:00:00 +0900</pubDate>
      </item>
      
   </channel>
</rss>
