三分一技術士事務所

『国連CEFACT標準準拠 業界横断EDI仕様の技術審査要領』のスキーマ設計例とUN/CEFACT NDR 2.1.1の比較

Views: 4

この記事を書いた後、次の文書が公開されており、『技術審査要領』で規定された方式がMessage Construction Guidelines for CCBDAにおいてDocument Centric (DC) approachとして規定されているとご教示いただきました。Document Centric (DC) approachについては、こちらの記事
『UN/CEFACTにおけるCCBDAに基づくDocument Centricなメッセージ構築方式』
をお読みください。

The UN/CEFACT have published several Standard Messages in XML Schema those which are importing all the Reusable ABIEs of the published Core Component Library (CCL).

The Core Components Business Document Assembly (CCBDA) Technical Specification can be employed wherever business information is being shared or exchanged amongst and between enterprises, governmental agencies and/or other organizations in an open environment. This environment can be of a worldwide scope or restricted to a specific business context (such as an industry or region).
UN/CEFACTは、XMLスキーマでいくつかの標準メッセージを公開しており、それらは公開されたコアコンポーネントライブラリ（CCL）のすべての再利用可能なABIEをインポートしている。コア・コンポーネント・ビジネス・ドキュメント・アセンブリ（CCBDA）技術仕様は、オープンな環境で企業、政府機関、その他の組織の間でビジネス情報が共有、交換される場合に採用することができる。この環境は、世界的なものであっても、特定のビジネスコンテキスト（業界や地域など）に限定されたものであってもよい。

The UN/CEFACT published message assemblies (MA) can be customized by user communities using the CCBDA methodology. This methodology can be applied on all message assemblies by the Document Centric (DC) or the Reference Data Model (RDM) approach.
UN/CEFACTの公開メッセージ・アセンブリ（MA）は、CCBDA手法を使用してユーザー・コミュニティによってカスタマイズすることができます。この手法は、ドキュメント・セントリック（DC）または参照データ・モデル（RDM）アプローチによって、すべてのメッセージ・アセンブリに適用することができます。

Document Centric (DC) approach: A collection of information used within a specific business process, structured in such a way that it covers the business data exchange needs. DC message may be published for a specific document by a specific industry domain group, a specific local group or a specific user group using restricted BIEs according to the rules of CCBDA.
ドキュメントセントリック（DC）アプローチ： 特定のビジネスプロセス内で使用される情報の集まりで、ビジネスデータ交換のニーズをカバーするように構造化されている。DCメッセージは、CCBDAのルールに従って、特定の業界ドメイングループ、特定のローカルグループ、または制限されたBIEを使用する特定のユーザーグループによって、特定のドキュメントに対して発行される。

Reference Data Model (RDM) approach: A collection of Reference Business Information Entities (Reference BIEs) structured in such a way that it covers the business data exchange needs within a specific domain which can be even further restricted by a particular industry group, a specific local group or a specific user group according to the rules of CCBDA. The main differences between the DC approach is that only Reference BIEs instead of Messages BIEs are in scope. The business needs are reflected by contextualizing Reference BIEs. This collection of Reference BIEs is also known as a “Context CCL” or “Contextualized subset of the CCL”. Regarding the message assembly the same CCBDA rules are being applied, but, as written, on the contextualized Reference BIEs instead of the Messages BIEs residing in the CCL.
参照データモデル(RDM)アプローチ： リファレンス・ビジネス・インフォメーション・エンティティ（リファレンスBIE）の集合で、特定のドメイン内のビジネスデータ交換ニーズをカバーするように構造化されており、CCBDAのルールに従って特定の業界グループ、特定のローカルグループ、特定のユーザーグループによってさらに制限することができる。DCアプローチとの主な違いは、メッセージBIEではなく参照BIEのみが対象であることです。ビジネスニーズは、参照BIEを文脈化することで反映されます。この参照BIEの集まりは、「コンテキストCCL」または「CCLのコンテキスト化されたサブセット」とも呼ばれる。メッセージのアセンブリに関しては、同じCCBDAルールが適用されますが、CCLに存在するメッセー ジBIEではなく、文脈化された参照BIEに適用されます。

DeepLにて翻訳

— UN/CEFACT Message Construction Guidelines for CCBDA Version 1.0 31 August 2020
4. Message Construction Approach

本稿では、『国連CEFACT標準準拠 業界横断EDI仕様の技術審査要領』におけるXMLスキーマ設計例について解説し、UN/CEFACTのXML Naming and Design Rules（NDR）2.1.1との比較を行います。まず、NDR2.1.1に準拠した設計例（p23）では、ABIE（Aggregate Business Information Entity）などの再利用可能な型を外部スキーマで定義し、RootSchemaからimportする「Venetian Blindパターン」が採用されています。これにより、再利用性や保守性、拡張性が高まる設計となっています。一方、技術審査要領では国内業界横断EDIの実運用例として、必要なABIEをRootSchema内で直接定義する「Russian Dollパターン」が示されています。この方式は運用効率や実装の容易さを重視していますが、再利用性や標準準拠性は低くなります。さらに、両パターンを含む代表的なXMLスキーマ設計パターン（Russian Doll、Salami Slice、Venetian Blind、Garden of Eden）の特徴や利点・欠点を整理し、利用目的や運用規模に応じた設計パターン選択の重要性について指摘します。総じて、国際標準と国内実務における設計思想の違いを明確にし、現場での実装選択に資する知見を提供します。

1. 対象文書

『国連CEFACT標準準拠 業界横断EDI仕様の技術審査要領』(2019 年2月 国連CEFACT日本委員会 登録技術審査グループ)
UN/CEFACT XML Naming and Design Rules Version 2.1.1

2. 『技術審査要領』p23: NDR準拠のスキーマ設計例

（３）XMLスキーマ生成

国連CEFACTの標準メッセージ用XMLスキーマは、メッセージを構成するMAおよびASMAのみをメッセージごとに定義し、それ以下のABIEはReusable ABIEモジュールに全てを詰め込んだ形で定義されている（図２－９）。

この場合、どのメッセージを定義するにも共通辞書にある全てのABIE（Reusable ABIE）をImportしており、メッセージとして重たくなっている。またReusable ABIEのセットはバージョン毎に単一であり、追加申請中のABIEを含む可能性のある業界横断EDI 仕様メッセージ定義にはそぐわない。

Fig2 9

— 業界横断EDI仕様の技術審査要領
p23

2.1. 概要

  • p23では、UN/CEFACT NDR2.1.1に準拠した標準的なスキーマ設計例が示されている。

  • 文書スキーマ（rsm:RootSchema）は、Reusable ABIE Schema Module（ram:）、データ型スキーマ（qdt:、udt:）などをimportし、文書構造を定義。

  • ABIE（Aggregate Business Information Entity）は再利用可能スキーマ（ram:）で定義され、RootSchemaはそれをimportして利用する。

2.2. 特徴

  • ABIEは文書スキーマ内で定義せず、外部スキーマ（ram:）からimport。

  • NDR2.1.1の推奨設計（再利用性・保守性・拡張性重視）に合致。

2.3. 関連NDR規定

7.1.3

[R83] The rsm:RootSchema MUST import the following schema modules: ram:ReusableABIE, udt:UnqualifiedDataType, qdt:QualifiedDataType.

ルートスキーマは、その名前空間に存在するすべての内部スキーマモジュールを含む。ルートスキーマは、UN/CEFACT の命名規則および設計規則に準拠していれば、必要に応じて他の外部スキーマモジュールをインポートすることができる。あるルートスキーマ（ルートスキーマA）は、別のルートスキーマ（ルートスキーマB）またはそのルートスキーマの内部スキーマモジュールの一部として定義されたABIEを使用することもできる。つまり、別の名前空間で定義された型定義や要素宣言を再利用する。例えば、発注レスポンス・メッセージのルート・スキーマ（ルート・スキーマ A）は、発注依頼メッ セージのスキーマ定義（ルート・スキーマ B）の一部として定義された ABIE を使用する。もしそうであれば、そのような型定義と要素宣言はルートスキーマ（ルートスキーマ A）にインポートされなければならない。そのためには、必要な型定義と要素宣言を含む名前空間のルート・スキーマ（ルート・スキーマ B）のみをインポートし、それ自体が下位の内部スキーマ・モジュールを含むようにする必要があります。

www.DeepL.com/Translator（無料版）で翻訳しました。

— UN/CEFACT XML Naming and Design Rules Version 2.1.

ABIEはReusable ABIE Schema Moduleで定義し、RootSchemaからimportします。

<!-- p23: NDR準拠のスキーマ設計例（ABIEは外部スキーマで定義しimport） -->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:rsm="urn:example:invoice:rsm:1"
           xmlns:ram="urn:example:common:ram:1"
           targetNamespace="urn:example:invoice:rsm:1"
           elementFormDefault="qualified">

  <!-- 外部のReusable ABIE Schema Moduleをimport -->
  <xs:import namespace="urn:example:common:ram:1" schemaLocation="ReusableABIE.xsd"/>
  <xs:import namespace="urn:example:common:qdt:1" schemaLocation="QualifiedDataType.xsd"/>
  <xs:import namespace="urn:example:common:udt:1" schemaLocation="UnqualifiedDataType.xsd"/>

  <!-- 文書ルート要素 -->
  <xs:element name="Invoice" type="rsm:InvoiceType"/>

  <!-- 文書構造定義（必要なABIEはram:で参照） -->
  <xs:complexType name="InvoiceType">
    <xs:sequence>
      <xs:element name="IssueDate" type="xs:date"/>
      <xs:element ref="ram:BuyerParty"/>
      <xs:element ref="ram:SellerParty"/>
      <xs:element ref="ram:LineItem" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
</xs:schema>

<!-- ReusableABIE.xsd（外部スキーマ例） -->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:ram="urn:example:common:ram:1"
           targetNamespace="urn:example:common:ram:1"
           elementFormDefault="qualified">
  <xs:element name="BuyerParty" type="ram:PartyType"/>
  <xs:element name="SellerParty" type="ram:PartyType"/>
  <xs:element name="LineItem" type="ram:LineItemType"/>
  <!-- ... -->
</xs:schema>

3. 『技術審査要領』p24: 国内業界横断EDIの現実的スキーマ設計例

そこで、業界横断EDI仕様メッセージのXMLスキーマは、該当するメッセージで使われるABIEだけをComplex Typeの中に持ち込むこととした（図２－１０）。

Fig2 10

— 業界横断EDI仕様の技術審査要領
p24

3.1. 概要

  • p24では、RootSchema（文書定義スキーマ）内で必要なABIE（ComplexType）を直接定義する例が掲載されている。

  • 外部のReusable ABIEスキーマをimportせず、文書スキーマ内でABIEを定義している。

3.2. 特徴

  • ABIEをRootSchema内で直接定義（importしない）。

  • 再利用性や保守性よりも、運用効率や実装の現実性を優先した設計。

3.3. ガイドブックの記述

  • 「国連の標準を開発する手順であり、国内の業界横断EDI仕様による国内業界や企業グループのメッセージ設計にそのまま適用する必然性はない。」（p4）。

  • 国内運用の現実解として許容されているが、標準設計ではない。

4. NDR2.1.1との比較・違い

項目

p23（NDR準拠）

p24（国内現実設計例）

ABIE定義

ram:等の外部スキーマで定義

RootSchema内で直接定義

ABIE利用

importで利用

直接定義したものを利用

再利用性

高い

低い

保守性

高い

低い

NDR準拠性

準拠

非準拠（原則から外れる）

5. XMLスキーマ設計パターンの比較とp24の位置づけ

5.1. 各種XMLスキーマ設計パターンの概要

XMLスキーマには主に次の4つの設計パターンがあります。

設計パターン 特徴 利点 欠点

Russian Doll
ロシア人形

グローバル要素は1つのみ。
他のすべての要素はローカル。

・有効なルート要素が1つだけ
・elementFormDefaultを”unqualified”にすることで、ローカル要素に名前空間を付けなくても良くなるので、XMLの記述をシンプルにできます。

・要素の再利用はなし
・単一ファイルスキーマのみ対応

Salami Slice
サラミ・スライス

すべての要素がグローバル。
複数のルート要素の可能性あり。

・すべての要素が再利用可能
・他の文書からの再利用が可能

・名前空間の複雑さが露呈する
・ルート要素の特定が困難

Venetian Blind
ベネチアン・ブラインド

Russian Dollの拡張。
グローバル要素は1つ。他の要素はローカル。
すべての型がグローバル

・ルート要素は1つだけ
・すべての型と単一のグローバル要素の再利用が可能
・複数ファイルに対応

・型の公開によりカプセル化が制限される

Garden of Eden
エデンの園

Venetian BlindとSalami Sliceの組み合わせ。
すべての要素と型がグローバルで、複数のルート要素の可能性あり。

・要素と型の両方が再利用可能
・複数ファイルに対応

・ルート要素が多数存在
・型の公開によりカプセル化が制限
・読みづらく理解しづらい

5.2. 各パターンの例

5.2.1. ロシア人形 パターン（p24の例）

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

   <xs:element name="Invoice">
      <xs:complexType>
         <xs:sequence>
            <xs:element name="BuyerParty">
               <xs:complexType>
                  <xs:sequence>
                     <xs:element name="PartyName" type="xs:string"/>
                     <xs:element name="PartyID" type="xs:string"/>
                  </xs:sequence>
               </xs:complexType>
            </xs:element>
            <xs:element name="SellerParty">
               <xs:complexType>
                  <xs:sequence>
                     <xs:element name="PartyName" type="xs:string"/>
                     <xs:element name="PartyID" type="xs:string"/>
                     <xs:element name="QualifiedInvoiceIssuerID" type="xs:string"/>
                  </xs:sequence>
               </xs:complexType>
            </xs:element>
            <!-- ... -->
         </xs:sequence>
      </xs:complexType>
   </xs:element>
   <!-- ... -->
</xs:schema>

  • すべての型・要素が入れ子構造で、トップレベル要素以外は匿名型・ローカル要素。

  • 文書構造とスキーマ構造が一致し、シンプルだが再利用性は低い。

5.3. サラミ・スライス パターン

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

   <xs:element name="Invoice">
      <xs:complexType>
         <xs:sequence>
            <xs:element ref="BuyerParty"/>
            <xs:element ref="SellerParty"/>
            <!-- ... -->
         </xs:sequence>
      </xs:complexType>
   </xs:element>

   <xs:element name="BuyerParty">
      <xs:complexType>
         <xs:sequence>
            <xs:element name="PartyName" type="xs:string"/>
            <xs:element name="PartyID" type="xs:string"/>
         </xs:sequence>
      </xs:complexType>
   </xs:element>

   <xs:element name="SellerParty">
      <xs:complexType>
         <xs:sequence>
            <xs:element name="PartyName" type="xs:string"/>
            <xs:element name="PartyID" type="xs:string"/>
            <xs:element name="QualifiedInvoiceIssuerID" type="xs:string"/>
         </xs:sequence>
      </xs:complexType>
   </xs:element>
   <!-- ... -->
</xs:schema>

  • すべての要素がグローバル宣言。型は匿名またはローカル。

  • 同じ構造でも要素ごとに定義が必要で、型の再利用はできない。

5.4. ベネチアン・ブラインド パターン（NDR推奨）

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

   <xs:element name="Invoice" type="InvoiceType"/>

   <xs:complexType name="InvoiceType">
      <xs:sequence>
         <xs:element name="BuyerParty" type="PartyType"/>
         <xs:element name="SellerParty" type="QualifiedInvoiceIssuerPartyType"/>
         <!-- ... -->
      </xs:sequence>
   </xs:complexType>

   <xs:complexType name="PartyType">
      <xs:sequence>
         <xs:element name="PartyName" type="xs:string"/>
         <xs:element name="PartyID" type="xs:string"/>
      </xs:sequence>
   </xs:complexType>

   <xs:complexType name="QualifiedInvoiceIssuerPartyType">
      <xs:sequence>
         <xs:element name="PartyName" type="xs:string"/>
         <xs:element name="PartyID" type="xs:string"/>
         <xs:element name="QualifiedInvoiceIssuerID" type="xs:string"/>
      </xs:sequence>
   </xs:complexType>
   <!-- ... -->
</xs:schema>

  • 型（PartyType）はグローバルで再利用可能、要素（BuyerParty, SellerParty）はグローバルまたはローカル宣言。

  • 構造の再利用性が高く、保守性にも優れる。

5.5. エデンの園 パターン

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

   <xs:element name="Invoice" type="InvoiceType"/>   <xs:complexType name="InvoiceType">
      <xs:sequence>
         <xs:element ref="BuyerParty"/>
         <xs:element ref="SellerParty"/>
         <!-- ... -->
      </xs:sequence>
   </xs:complexType>

   <xs:element name="BuyerParty" type="PartyType"/>

   <xs:element name="SellerParty" type="QualifiedInvoiceIssuerPartyType"/>

   <xs:complexType name="PartyType">
      <xs:sequence>
         <xs:element name="PartyName" type="xs:string"/>
         <xs:element name="PartyID" type="xs:string"/>
      </xs:sequence>
   </xs:complexType>

   <xs:complexType name="QualifiedInvoiceIssuerPartyType">
      <xs:sequence>
         <xs:element name="PartyName" type="xs:string"/>
         <xs:element name="PartyID" type="xs:string"/>
         <xs:element name="QualifiedInvoiceIssuerID" type="xs:string"/>
      </xs:sequence>
   </xs:complexType>
   <!-- ... -->
</xs:schema>

  • すべての要素・型をグローバル宣言し、最大限の再利用性・拡張性を確保。

6. p24（Russian Dollパターン）の特徴とNDRとの関係

  • p24のスキーマ例はRussian Dollパターンであり、再利用性や拡張性よりも、文書単位での簡潔さや構造の明確さを重視している。

  • NDR2.1.1（UN/CEFACT推奨）はVenetian Blindパターンに近く、型の再利用や保守性を重視し、ABIEなどの再利用可能型をグローバル定義してimportする設計が推奨される。

  • Russian Dollパターンは単一文書向けにはシンプルで有効だが、スキーマの再利用や標準化には不向きとされる。

7. まとめ

  • p24のようなRussian Dollパターンは、国内業界横断EDI仕様の現実的運用例として採用されているが、国連CEFACT NDRの標準設計（Venetian Blind型）とは設計思想が異なる。

  • 利用目的や運用規模に応じて、適切なスキーマ設計パターンを選択することが重要である。

  • p23の設計例はUN/CEFACT NDR2.1.1に準拠しており、ABIEは再利用可能スキーマで定義し、RootSchemaでimportして利用する。

  • p24の設計例は、RootSchema内でABIEを直接定義しており、NDR2.1.1の原則（再利用性重視）とは矛盾する。

  • p24の設計は国内業界横断EDIの現実的な運用例として紹介されているが、標準設計ではない。

Share this…

投稿日

カテゴリー:

,

投稿者:

Nobuyuki

タグ:

コメント

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です