Hi Philip,
First off, thanks for phax/ddd as it's been useful for determining the correct doctype, ProcessID and VESID. I just had two clarifying questions while wiring up some additional value providers for syntax cii-d16b.
1. cii-d16b matches all CII versions — why is the ID D16B-pinned?
syntaxes.xml declares:
<syntax id="cii-d16b" nsuri="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100" root="CrossIndustryInvoice">
This is shared across every UN/CEFACT data release (D16B, D22B, …) — so the syntax already matches every CII document we receive, regardless of release version. But because the syntax ID is cii-d16b, I can't define a parallel cii-d22b syntax. It would compete on the same namespace+root and DDD wouldn't know which to pick.
The workaround is to add the D22B entries inside cii-d16b with <set id="SyntaxVersion">D22B</set> overrides, which feels backwards (the entries aren't really D16B).
Is this intentional? Would you be open to renaming cii-d16b → cii (version-neutral) so each value-provider entry can pin its own version much like the ubl2 value providers?
2. cii-d16b is the only default syntax that force-sets ProcessID
Every entry under <syntax id="cii-d16b"> carries an explicit <set id="ProcessID">…</set>, overriding the value already extracted by the syntax's own xpath:
<get id="ProcessID">
<xpath>*[local-name()='ExchangedDocumentContext']/*[local-name()='BusinessProcessSpecifiedDocumentContextParameter']/*[local-name()='ID']/text()</xpath>
</get>
The other default value-provider blocks don't do this. A consumer can't override either: DDDValueProviderList._recursiveMergeSelects rejects conflicting <set> values, and an override that omits ProcessID doesn't unset the default.
Is there a reason for<set id="ProcessID"> specifically in cii-d16b?
Happy to draft a PR for either (or both) if you can point me at the shape you'd accept!
PS: as you might have guessed, this came up while wiring up the new French entries in the Peppol code list v9.6 (POAC-France block, entries 271–278). Any plans to extend the bundled providers with those? I realise the AIFE/Chorus Pro specs aren't
fully aligned with what eventually landed in the codelist, so I'd understand if you're holding off until things get clearer. This is also something I would be willing to contribute to!
Thanks again!
Hi Philip,
First off, thanks for
phax/dddas it's been useful for determining the correct doctype, ProcessID and VESID. I just had two clarifying questions while wiring up some additional value providers for syntaxcii-d16b.1.
cii-d16bmatches all CII versions — why is the ID D16B-pinned?syntaxes.xmldeclares:This is shared across every UN/CEFACT data release (D16B, D22B, …) — so the syntax already matches every CII document we receive, regardless of release version. But because the syntax ID is
cii-d16b, I can't define a parallelcii-d22bsyntax. It would compete on the same namespace+root and DDD wouldn't know which to pick.The workaround is to add the D22B entries inside
cii-d16bwith<set id="SyntaxVersion">D22B</set>overrides, which feels backwards (the entries aren't really D16B).Is this intentional? Would you be open to renaming
cii-d16b→cii(version-neutral) so each value-provider entry can pin its own version much like the ubl2 value providers?2.
cii-d16bis the only default syntax that force-setsProcessIDEvery entry under
<syntax id="cii-d16b">carries an explicit<set id="ProcessID">…</set>, overriding the value already extracted by the syntax's own xpath:The other default value-provider blocks don't do this. A consumer can't override either:
DDDValueProviderList._recursiveMergeSelectsrejects conflicting<set>values, and an override that omitsProcessIDdoesn't unset the default.Is there a reason for
<set id="ProcessID">specifically incii-d16b?Happy to draft a PR for either (or both) if you can point me at the shape you'd accept!
PS: as you might have guessed, this came up while wiring up the new French entries in the Peppol code list v9.6 (POAC-France block, entries 271–278). Any plans to extend the bundled providers with those? I realise the AIFE/Chorus Pro specs aren't
fully aligned with what eventually landed in the codelist, so I'd understand if you're holding off until things get clearer. This is also something I would be willing to contribute to!
Thanks again!