Visits: 86
XMLスキーマとスキーマトロン
「OPEN PEPPOLのSHARED RULEにおける繰り返し回数制御」も併せて
Open PeppolのDXについてはこちらをお読みください。
Open Peppolの４コーナーモデルでは、C2でデジタルインボイスがOpen Peppolが規定している論理モデルのデータ項目定義（セマンティックモデル）に違反していないか検証することで、不正なデータが使用されていないことを保証しています。
データ項目の妥当性検証は、先づXMLスキーマ定義に違反していないか検証し、次にスキーマトロンでデータ項目定義がセマンティックモデル定義に違反していないか検証しています。
現在使用されているBIS Billing 3.0では、UBLで定義されていてもセマンティックモデルでは定義されていないデータ項目（シンタクスバインディングに未登録のUBLで定義されているXML要素）をチェックしてメッセージを発行しています。このルール群をBasic rulesと呼びます。
Open peppolからダウンロードできる次のスキーマトロンファイルには、
Schematron for TC434 rules (UBL)
次のように、UBLで定義していてもBIS Billing 3.0のデジタルインボイスでは使用しないこととされている項目に対するチェックが約600件提供されています。
<rule context="/ubl:Invoice | /cn:CreditNote">
<assert id="UBL-CR-001" flag="warning" test="not(ext:UBLExtensions)">[UBL-CR-001]-A UBL invoice should not include extensions</assert>
<assert id="UBL-CR-002" flag="warning" test="not(cbc:UBLVersionID) or cbc:UBLVersionID = '2.1'">[UBL-CR-002]-A UBL invoice should not include the UBLVersionID or it should be 2.1</assert>
<assert id="UBL-CR-003" flag="warning" test="not(cbc:ProfileExecutionID)">[UBL-CR-003]-A UBL invoice should not include the ProfileExecutionID </assert>
<assert id="UBL-CR-004" flag="warning" test="not(cbc:CopyIndicator)">[UBL-CR-004]-A UBL invoice should not include the CopyIndicator </assert>
省略
</rule>
このルール群が、現在公開中のJP PINT 0.9.1では、廃止されています。JP PINT 0.9では、提供されていましたが、Distinctの拡張を許すにはチェックルールは不要との判断のようです。
ここで、XMLスキーマとスキーマトロンの妥当性検証の違いについて整理すると、次のようにまとめることができます。
XMLスキーマ定義
• XML要素定義と複数のXML要素を組み合わせたXML文書モデルを定義
• XML要素のデータ型とその形式定義
• 複合型の要素がどのような要素を含むかといった構造定義と要素の出現順や繰返し回数定義
• 上記の定義に違反しているXML要素があればエラーが報告される。
つまり、明示的に定義されていないものは全て禁止される。
スキーマトロン
• ルール定義が主
• 項目間の依存関係や取りうる値についての関係を定義し、それに違反していればエラーとする。
• 複雑な関係の定義も可能
つまり、明示的に禁止しないものは許容される。
C2に対するComplient要件
現在公開中のJP PINT 0.9.1では、次の要請が提示されています。
PINT compliance
This section defines how compliance to PINT is measured and what are the requirements and expectations for the relevant parties.
Senders compliance to BIS
Processing of rules
A sender SHALL NOT send messages that are not compliant to the BIS.
A sender shall validate an outgoing message that are in line with the customsation identifier.
ここで、complientがどういったことを意味するのか、正確に確認する必要があります。
一般のビジネスにおける契約書と同様に普通の英単語として解釈するのでなく記述されている文脈における正確な意味を解釈することが技術標準の読解においても不可欠です。
EN 16931-1でのTerms and conditionでは、
第3章の「用語と定義」
3.11
compliant
some or all features of the core invoice model are used and all rules of the core invoice model are respected
コア請求書モデルで定義している一部またはすべての機能が使用され、コア請求書モデルのすべてのルールが適用される
Note 1 to entry: Based on TOGAF definition of a compliant specification [18].
3.12
conformant
all rules of the core invoice model are respected and some additional features not defined in the core invoice model are also used
コア請求書モデルのすべてのルールが適用されるが、コア請求書モデルで定義されていないいくつかの追加機能も使用される
Note 1 to entry: Based on TOGAF definition of a conformant specification [18].
それぞれ定義の基になっているのはTOGAFの”Levels of Architecture Compliant”定義です。
TOGAFは、２１世紀初頭にブームになったEnterprise Archtectire (EA)の標準を定めているOpengroupが規定している標準です。
Consistent:
The implementation has some features in common with the architecture specification, and those common features are implemented in accordance with the specification. However, some features in the architecture specification are not implemented, and the implementation has other features that are not covered by the specification.
実装にはアーキテクチャ仕様と共通の機能がいくつかあり、それらの共通機能は仕様に従って実装されています。 ただし、アーキテクチャ仕様の一部の機能は実装されておらず、実装には仕様でカバーされていない他の機能があります。
Compliant:
Some features in the architecture specification are not implemented, but all features implemented are covered by the specification, and in accordance with it.
アーキテクチャ仕様の一部の機能は実装されていませんが、実装されているすべての機能は仕様の対象であり、仕様に準拠しています。
Conformant:
All the features in the architecture specification are implemented in accordance with the specification, but some features are implemented that are not in accordance with it.
アーキテクチャ仕様のすべての機能は仕様に従って実装されていますが、一部の機能は仕様に従って実装されていません。
Basicルールがないと
アーキテクチャ仕様の一部の機能は実装されておらず、実装には仕様でカバーされていない他の機能があります。
UBLで定義されていてシンタックスバインディングで未定義のXML要素をエラー報告できない。
ということになりますので、C2ではConsistentであるかは検証できますが、Compliantかは検証できないので問題です。
Basic rulesを世界共通仕様としてのShared rulesに含めることは、Disitinct拡張を阻害するので、含めないのが妥当ですが、AlignedおよびSharedの項目定義について世界中のそれぞれの地域で管轄するPeppol Authorityが承認し、Open Peppolに登録する仕様として制定するので、それぞれの拡張仕様で規定されていないXML要素をエラーとするスキーマトロンルールをCustomization ID毎に整備することで対応可能と思うのですが。
