この件は、今回の Help Center への一連の問い合わせの端緒となった案件である。

JP PINT 導入時の検討作業で知り合った関係者に対し、まず私は、Peppol Invoice Response transaction 3.1 (T111) の公開ドキュメントに見られる不整合について、メールで確認を求めた。照会先は当時の検討作業を通じて面識のあった関係者であるが、本稿では匿名の「知人」として扱う。

私からの照会では、公開されている rule page において PEPPOL-T111-B03201 が次のように示されていることを指摘した。

これを Schematron として文字どおりに読むと、cac:Status の配下にある子要素はすべて不正となるように見える。しかし、同時に公開されている syntax page では、cac:Status の子要素として次の要素が許容されている[1]。

そのため、公開ルールと公開構文が整合していないように見えること、また rule page が実際の executable Schematron そのものではなく、説明用または自動生成された派生表現なのではないか、という疑問を伝えた。

この問い合わせに対し、知人からは、たしかに不整合があるように思われるが、自身およびもう一人の関係者はこの件の直接の担当ではない、とのコメントがあった。あわせて、別の担当者に確認を回してもらった結果、正式に処理するためには Peppol Help Center に bug report として登録してほしい、との案内を受けた。

つまり、知人からは「不整合らしい」という認識は示されたものの、その場で内容の正否を確定するのではなく、OpenPeppol の正式な窓口である Help Center に起票して処理すべき案件として扱われたことになる。

この経緯を受けて、本件を Help Center に登録した。さらに、2023 年の JP PINT 公開当初から未解決のままで、改善の兆しも見えない関連事項についても、この機会にあわせて追加で問い合わせることにした。

知人からの返信の要旨は、次のとおりである。

このコメントは、内容面で違和感があること自体は共有された一方で、正式な確認と対応は Help Center を通じて行うべきである、という立場を示したものであった。

Peppol Invoice Response transaction 3.1 (T111) の公開ドキュメントについて、cac:Status の構文説明と、ルール PEPPOL-T111-B03201 の公開ページに表示されている内容との間に、整合しないように見える点がある。

構文ページでは cac:Status の子要素として次の要素が許容されている[1]。

一方、ルールページ PEPPOL-T111-B03201 では次のように表示されている[2]。

この表示を Schematron ルールとして文字どおりに読むと、cac:Status 配下の子要素はすべて常に不正となるように見える。そのため、公開されている構文説明とルール表示が矛盾している可能性がある。

この指摘の主旨は、単にルール表示の誤記を疑うというだけではない。実装者が公開ドキュメントを参照して仕様を理解しようとした際に、どちらを正として解釈すべきか判断できず、誤った実装や誤解を招くおそれがある点にある。

特に、公開されたルールページの表示が、実際にバリデータで用いられている実行可能な Schematron をそのまま示しているのか、それとも自動生成された説明用の表現なのかが不明確であることが問題である。

Help Center には、公開されている cac:Status の構文ページと rule page の間に次のような不整合があると説明した。

公開されている cac:Status の構文ページでは、以下の子要素が明示的に許容されている。

しかし、公開されている PEPPOL-T111-B03201 のルールページでは、次のように表示されている。

これをそのまま実行ルールとして解釈すると、cac:Status の下に存在する任意の子要素は常にバリデーションエラーになるように見える。これは、構文ページで同要素の子要素が許容されているという説明と両立しない。

そのため、公開されているルールページは、実際にバリデータで実行される Schematron を正確に示しているのではなく、自動生成された説明用表現、あるいは別の派生表現なのではないか、という疑問が生じると指摘した。

この指摘では、Help Center に対して次の点の確認を求めた。

この照会の目的は、仕様書の誤りを断定することではなく、公開ドキュメントのどの情報を実装上の根拠として参照すべきかを明確にすることにある。

特に Invoice Response は、JP PINT では現時点で未対応であっても、今後の自動化された取引処理において重要な役割を持つ可能性がある。そのため、仕様と検証挙動の関係を正しく理解しておく必要がある。

また、本件は、Help Center に対する今回の一連の問い合わせの出発点となったという意味でも重要である。単独の表記揺れや誤記として片づけるのではなく、公開仕様の見せ方そのものが実装者にどのような解釈を与えるか、という観点から捉える必要がある。

Syntax binding の item page において、本来の Business Term ID である IBT-xxx ではなく、SB-IBT-xxx のような接頭辞付きのコードが表示されている。

Help Center の説明によれば、この SB- 接頭辞は仕様生成システムによって付与される field-level の内部的な識別子であり、不具合ではないとされている。しかし、利用者から見ると、この表示は Business Term ID と同じコード体系であるかのように見え、誤解を招くおそれがある。

そのため、たとえ内部的には別用途の識別子であっても、仕様上に表示するのであれば、Business Term ID とは異なる種類の識別子であることを、用語上も表示上も明確に区別すべきである、という指摘である。

問題は、単に SB- という接頭辞が存在すること自体ではない。問題なのは、その表示が仕様利用者に対して、あたかも Business Term ID の正式なコード体系の一部であるかのような印象を与えてしまう点にある。

Semantic Model や Syntax Binding で定義される Business Term ID は、意味的に定義された正式な識別子である。それに対して、SB-IBT-xxx は Help Center の説明によれば、仕様生成システム上の別目的の識別子である。したがって、この両者は同じコード体系として扱うべきではない。

にもかかわらず、見た目が似た形で表示されると、利用者は SB-IBT-xxx を正式な BT ID だと誤認しやすく、仕様理解や実装時に不要な混乱を招く。

Syntax binding item page に表示されている SB-IBT-xxx は、Business Term ID である IBT-xxx と異なる識別子であるにもかかわらず、利用者には両者の違いが明確に示されていない。

そのため、仕様利用者の立場からは、次のような懸念がある。

この回答に対して、SB-IBT-xxx は Business Term ID とは異なるコード体系である以上、仕様に表示するのであれば、単に「無視してください」と説明するのではなく、Business Term ID とは別種の識別子であることを、用語・ラベル・説明において明確に区別すべきであると再指摘した。

仕様利用者の観点では、内部実装上の都合であるかどうかよりも、公開された仕様書の表示が誤解を招かないことの方が重要である。

現時点で確認できる状況は、次のとおりである。

この件は、単なる表示上の細部ではなく、「仕様書において、何が正式な識別子で、何が内部生成の補助的識別子なのか」を明確に区別するという、仕様記述の基本に関わる問題である。

特に、Business Term ID は意味定義に直結する識別子であり、実装者が仕様を読む際の重要な参照点である。そのため、それに似た形式の別コードを無説明で並べて表示することは避けるべきである。

もし SB-IBT-xxx のような識別子を仕様上に残す必要があるのであれば、少なくとも以下のいずれかの対応が望ましい。

JP PINT の Invoice Transaction に関する syntax binding 文書において、Seller Party Tax に対応する cac:PartyTaxScheme の selector 式に誤りがあると考えられる。

公開ページでは selector が cac:TaxScheme = "VAT" と表示されているが、cac:TaxScheme は複合要素であり、実際に tax scheme code を保持しているのはその子要素である cbc:ID である。したがって、selector は cac:TaxScheme 自体ではなく、cac:TaxScheme/cbc:ID の値を判定すべきである。

この問題は詳細ページだけでなく Syntax binding overview にも同様に現れており、個別ページの単純な誤記ではなく、ドキュメント生成処理に起因する不具合である可能性が高い。

この問題の本質は、syntax binding に記載される selector が XML 構造を正しく反映していない点にある。

cac:TaxScheme は aggregate 要素であり、その内部の cbc:ID が tax scheme code を表す。したがって、cac:TaxScheme = "VAT" という比較は、XML 構造に照らすと不適切である。正しくは cac:TaxScheme/cbc:ID = "VAT" のように、子要素の値を参照すべきである。

このような selector 誤りは、仕様利用者が binding 条件を理解し実装に反映する際に、誤った XPath 理解を招くおそれがある。

Seller Party Tax の detail page において、公開されている selector は次のようになっていた。

しかし、同じ syntax binding page 上の XML 構造表示を見ると、cac:TaxScheme は複合要素であり、その中の cbc:ID が IBT-031-1 Tax scheme code に対応している。したがって、意図された selector は次のようなものであるべきだと指摘した。

さらに、同じ問題は Syntax binding overview にも現れていた。

これらについても、正しくは次のように表示されるべきであると考えられる。

この誤りは detail page と overview page の双方に同じ形で現れているため、単一ページの手修正漏れではなく、documentation generation process 側に起因する不具合である可能性が高い。

そのため、個別ページだけを順次修正するのではなく、selector を生成するロジック全体を見直すべきである、という点もあわせて指摘した。

現時点で確認できる状況は、次のとおりである。

この件は、syntax binding の記述において、XPath ないし XPath に類する selector 表現が XML 構造と整合していなければならないという基本的な要件に関わる。

特に、cac:TaxScheme のような aggregate 要素を、あたかも単純値のように直接比較する表現は、仕様利用者に誤った理解を与えかねない。しかも、同じ誤りが複数ページに繰り返し現れていることから、利用者側の読み違いではなく、公開文書側の生成ロジックに原因があると見るのが自然である。

このため、今回の修正では個別箇所の訂正にとどまらず、同種の selector 誤りが他にもないか、生成規則全体を確認することが望ましい。

JP PINT Version 1.1.2 の Invoice Transaction に関する syntax binding において、IBG-37（DOCUMENT TOTALS IN TAX ACCOUNTING CURRENCY）に対応する cac:TaxTotal の selector 式に誤りがあると考えられる。

公開ページでは、税会計通貨に対応する cac:TaxTotal を選択する selector として次の式が示されていた。

しかし、この式は UBL の XML 構造に照らして不正確であり、XPath としても selector の書き方としても適切ではない。具体的には、要素名・属性名・比較対象の参照位置・predicate の書き方に問題がある。

この件は、cac:TaxTotal をどの条件で選択するかという syntax binding の中核的な記述に関わる。

請求書では cac:TaxTotal が複数現れることがあり、document currency に対応するものと tax accounting currency に対応するものとを、selector により正しく区別する必要がある。もし selector が誤っていれば、実装者はどの TaxTotal が IBG-37 / IBT-111 に対応するのかを正しく理解できず、実装や変換処理に誤りを生じるおそれがある。

公開ページでは、IBG-37 に関する selector として次の式が示されていた。

この式には、少なくとも次の問題がある。

そのため、意図された selector は、少なくとも次のような形で表されるべきだと指摘した。

さらに、XMLSpy で確認した XPath として、次の式が期待どおりに tax accounting currency に対応する cac:TaxTotal を返すことを示した。

この式は、IBG-37 / IBT-111 の意図に合致すると考えられる。

同種の問題は、通常の tax total selector にも存在していた。

syntax overview では、次の selector が表示されていた。

これについても、要素名・属性名・文書レベル参照の点で同様の問題があり、公開されている syntax binding の selector 生成処理に体系的な不備がある可能性が高い。

現時点で確認できる状況は、次のとおりである。

この件は、syntax binding に記載される XPath selector が、XML の構造と名前空間、属性名、評価文脈を正しく反映していなければならないという基本的な要件に関わる。

特に今回の問題では、次のような複数のレベルの誤りが重なっていた。

このような selector は、実装者にとって仕様の理解を困難にし、正しい XPath の再構成を強いることになる。しかも、同種の誤りが複数箇所に現れていることから、個別の修正だけでなく、syntax binding を生成するロジック全体を見直すことが望ましい。

JP PINT Invoice documentation の Card Payment に関する説明では、cbc:NetworkID について複数の異なる扱いが同時に示されており、実装者にとって解釈が難しい状態になっている。

BIS の Card Payment ガイダンスでは、cbc:NetworkID に VISA を設定した例が掲載されており、本文でもこの要素は金融サービスネットワーク提供者を識別するための必須項目であり、VISA、MasterCard、American Express などの値を用いると説明されている[7]。

一方で、JP PINT Invoice の syntax binding では、cac:PaymentMeans/cac:CardAccount/cbc:NetworkID について「Syntax required element not mapped to a business term. Use value NA」と記載されており、親要素である cac:CardAccount のページでも同様の扱いが示されている[8][18]。

さらに、semantic model の IBG-18 PAYMENT CARD INFORMATION には IBT-087 Payment card primary account number と IBT-088 Payment card holder name は存在するが、NetworkID に対応する Business Term は定義されていない。それにもかかわらず、syntax binding overview では cbc:NetworkID が IBG-18 の配下に表示されている[9]。

この件の問題は、cbc:NetworkID が syntax 上は必須である一方、semantic model 上は Business Term に対応付けられておらず、しかも公開文書では実値を入れる例と NA を入れる指示が併存している点にある。

その結果、実装者から見ると、少なくとも次の三つの説明が同時に成立しているように読めてしまう。

これは単なる表現上のゆれではなく、実装時の値設定に直接影響する実質的な矛盾である[10]。

Help Center には、公開資料の現状が次のような矛盾した読み方を許してしまっていると指摘した。

そのため、cbc:NetworkID に実際のカードネットワーク識別子を入れるのが正しいのか、それとも固定値 NA を入れるべきなのか、実装者が判断できない状態になっている。

この点について、BIS 文書、semantic model、syntax binding の間で整合した説明を示すよう求めた。

この説明を受けて、NA が常に要求されるのではなく、実際のカードネットワーク値が分かる場合にはその値を記入してよい、という理解で正しいかを確認した。

この clarification に対して、さらに次の点をコメントした。

cbc:NetworkID の使用を OpenPeppol が認めるのであれば、本来はそれに対応する official Business Term が正式に登録されるべきである。BT が存在しないままでは、この要素は「syntax 上必須なのでとりあえず埋める項目」と「意味をもって実値を入れてよい項目」の中間に置かれたままとなり、準拠実装上の意味が不明確になる。

したがって、cbc:NetworkID は単に NA を入れるための syntax-level field と理解されるべきではなく、カードネットワークが分かる場合にはその実値を提供しうる、意味の明確な要素として整理されるべきである。そのためには、対応する official BT の整備と、それに沿った documentation および syntax binding の見直しが望ましいと指摘した。

現時点で確認できる状況は、次のとおりである。

この件は、syntax requirement と business semantics のずれが、そのまま公開仕様の曖昧さとして現れている典型例である。

UBL 構文上は必須でも、semantic model に対応する BT がなければ、仕様利用者はその値の意味や扱いを一貫して理解しにくい。しかも今回は、BIS では実値の例を示しながら、syntax binding では NA 使用を促すように読めるため、実装者は「実値を入れてよいのか」「NA を固定で入れるべきか」を判断できなくなる。

今回の Help Center 回答により、少なくとも現時点の解釈としては、「実値が分かれば実値を入れてよく、NA は fallback である」ことが明確になった。この clarification 自体は重要である。

ただし、より本質的には、意味をもって使うことを認めるのであれば、それに対応する official BT が必要である。EN 16931 にその BT が存在しない以上、OpenPeppol としてどう扱うかは今後の検討課題であり、単なる文言修正だけでは解決しない論点を含んでいる。

JP PINT の Invoice Transaction に関する syntax binding 文書において、bank assigned creditor identifier に対応する cac:PartyIdentification の selector 式に誤りがあると考えられる。

公開ページでは selector が cac:ID/@schemeID = "SEPA" と表示されているが、同じページで示されている child element は cbc:ID である。したがって、cac:PartyIdentification を子要素の識別子に基づいて選択するのであれば、selector は cac:ID ではなく cbc:ID を参照すべきである。

この問題は overview と detail page の双方に現れており、個別ページの単純な誤記ではなく、selector 生成処理に起因する不具合である可能性がある。

この件の本質は、syntax binding に記載される selector が、同じページで示されている XML 構造と整合していない点にある。

公開ページでは、対象となる要素は cac:PartyIdentification であり、その child element は cbc:ID として示されている。それにもかかわらず selector が cac:ID/@schemeID = "SEPA" となっているため、実装者から見ると、どの要素を条件判定の対象としているのかが不明確になる。

このような selector 誤りは、仕様利用者が binding 条件を誤って理解する原因となるだけでなく、syntax binding 文書全体の信頼性にも影響する。

公開されている syntax binding overview の cac:AccountingSupplierParty / cac:Party の箇所では、Bank assigned creditor identifier に対して次の selector が表示されている。

また、cac:PartyIdentification の detail page においても、selector は次のように表示されている。

しかし、同じ detail page で child element として示されているのは次の要素である。

したがって、cac:PartyIdentification を child identifier の @schemeID = "SEPA" という条件で選択するのであれば、selector は cac:ID ではなく cbc:ID を参照すべきである。

そのため、意図された selector は次のようなものである可能性が高い。

この件は単独の誤記ではなく、selector 生成処理の問題である可能性がある。

実際、類似の問題として、cac:PartyTaxScheme の selector が cac:TaxScheme = "VAT" と表示されていた件が、すでに PEPPOL-22907 として報告されている。そのため、今回の件も個別ページのみの修正ではなく、selector-generation tool 自体の点検対象と考えるのが自然である。

また、もし selector 生成ツールに問題があるのであれば、JP PINT 以外の jurisdiction-aligned PINT specifications においても、同様の誤りが含まれている可能性がある。

この件では、Help Center に対して次の点を依頼した。

この件については、SEPA という値自体の妥当性を問題にしているのではなく、あくまで selector の記述が XML 構造と一致していない点を問題にしている。

その意味で、修正すべきは rule の厳しさではなく、syntax binding 文書の selector 表示である。さらに、すでに類似の selector 誤りが別件で報告されていることから、個別ページを都度手修正するだけでなく、selector-generation tool の不具合有無を確認することが重要である。