[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] How to avoid data duplication in schematron files?
- From: Svante Schubert <svante.schubert@gmail.com>
- To: Andrew Sales <andrew@andrewsales.com>
- Date: Wed, 17 Apr 2019 16:38:05 +0200
Hi Andrew,
Thanks for the pointer.
Jirka Kosek was so kind to give me offline support, so I figured it
out by his guidance.
The final solution if anybody ever stumbles into a similar problem:
File A with distinct XML contexts, e.g. CII:
<pattern xmlns="http://purl.oclc.org/dsdl/schematron"
id="EN16931-Codes-CII" is-a="EN16931-Codes">
<param name="BR-CL-01-CONTEXT" value="rsm:ExchangedDocument/ram:TypeCode"/>
<!-- further parameters -->
</pattern>
File B with common rules:
<pattern xmlns="http://purl.oclc.org/dsdl/schematron"
id="EN16931-Codes" abstract="true">
<rule context="$BR-CL-01-CONTEXT" flag="fatal">
<assert
test="((not(contains(normalize-space(.), ' ')) and contains(' 80
81 82 83 84 130 202 203 204 211 261 262 295 296 308 325 326 380 381
383 384 385 386 387 388 389 390 393 394 395 396 420 456 457 458 527
532 575 623 633 751 780 935 ', concat(' ', normalize-space(.), '
'))))"
id="BR-CL-01"
flag="warning">[BR-CL-01]-The document type code MUST be coded
by the invoice and credit note related code lists of UNTDID
1001.</assert>
</rule>
<!-- further rules -->
</pattern>
Best,
Svante
Am Mo., 15. Apr. 2019 um 13:14 Uhr schrieb Andrew Sales
<andrew@andrewsales.com>:
>
> Hi Svante, just to mention - there is also a Schematron mailing list now:
> http://schematronist.org/mailman/listinfo/schematron_schematronist.org
>
> Regards,
> Andrew
>
> On Mon, 15 Apr 2019 at 09:00, Svante Schubert <svante.schubert@gmail.com> wrote:
>>
>> I have recently started to take a closer look at the EU e-invoice schematron validator and need some tip how data duplication could be avoided in this project (find some basic background in the end of the email).
>> In this project some schematron files are quite identical for different formats, as the rules to be tested rely on the semantic model or on common parts called code lists.
>> I already described the problem in an issue, but it was closed, I fear due to the lack of knowledge how to handle it. Therefore I would like to provide an example, as I believe it should work somehow..
>>
>> Let's take a look at the two code list files, being close to equal:
>> validation\ubl\schematron\codelist\EN16931-codes.sch
>> validation\cii\schematron\codelist\EN16931-CII-codes.sch
>> The files should only differ in the context being used.
>>
>> It's been more than fifteen years since I used XPath/XSLT, so I was a little rusty, but I thought the 'calling' schematron file
>> (see https://github.com/CenPC434/validation/blob/master/cii/schematron/EN16931-CII-validation.sch)
>> should simply provide the context as parameters, like a module is calling a sub-module.
>> It did not work out, as <sch:include> does now allow any children such as parameter.
>> You may see my erroneous approach as GIT diff, making the schematron pattern abstract and providing the varying context from the caller.
>>
>> Could someone point me into a problem-solving direction, please?
>>
>> Thanks in advance,
>> Svante
>>
>> PS: Some basic background:
>> The EU requires from its member states to accept electronic XML invoices either based on UBL or CII (UN/CEFEACT cross-industry invoice) called EN 16931.
>> The elegant trick they have been using is to define a semantic model and map it to each XML format. The first two parts of the spec are free available, the mapping is not.
>>
>>
>>
>>
>>
>>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]