Rules with attribute as context (UBL)

[klakegg]

The following rules has a context targeting an attribute:

• BR-CL-03
• BR-CL-23
• BR-CL-24

Those rules will not trigger when implementers use the official ISO Schematron stylesheets to generate the XSLT version.

[oriol]

The problem affects all contexts targeting an attribute.

It seems it is a bug in Schematron's official stylesheets.

https://stackoverflow.com/questions/40045725/when-using-xslt-2-schematron-ignores-rules-that-have-attributes-in-their-contex

The second solution described in the link above seems the best solution.

[phax]

It is an official Schematron bug acknowledged in Schematron/schematron#29

[SiwMeckelborg]

I think these rules rather should be rewritten, to not have the attribute as the context. Either have the cbc:*[@Attribute], or possibly even better for performance issues, add the effected elements as context, like this:

<rule context="cbc:Amount | cbc:BaseAmount | cbc:PriceAmount >
All currencyID attributes must have the same value as the invoice currency code (BT-5), except for the invoice total VAT amount in accounting currency (BT-111)

[oriol]

I am not sure this will work, as it seems the error in the ISO files affect any context ending with and attribute. Best Oriol

…

El 8 febr 2018, a les 18:47, Siw Meckelborg ***@***.***> va escriure: I think these rules rather should be rewritten, to not have the attribute as the context. Either have the ***@***.*** <https://github.com/attribute>, or possibly even better for performance issues, add the effected elements as context, like this: <rule context="cbc:Amount | cbc:BaseAmount | cbc:PriceAmount > All currencyID attributes must have the same value as the invoice currency code (BT-5), except for the invoice total VAT amount in accounting currency (BT-111) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#50 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAZSFDMfkz1PXqfjo6f4mAd_XSzqYTR_ks5tSzMfgaJpZM4R7snz>.

[SiwMeckelborg]

Changed my comment, as the first variant was wrong, any /@Attribute will have the same problem. But as stated, I think the best solution is to name all elements, to prevent it from looping through all elements looking for the attribute.

[oriol]

The issue is on the stylesheets generating the XSLTs from the Schematron files, so I would not recommend changing the context but asking official Schematron to fix their bug.

[phax]

Which will not happen quickly, because they don't have a test suite and afraid of side effects ;-) Maybe XSpec will be used to build up a test-suite in the future.... I would add this as a "known issue" and link to the fix. The official Schematron stylesheets are also not compatible with Saxon 9.8 because they are XSLT v1 and Saxon 9.8 only supports XSLT v2...

[SiwMeckelborg]

I think it is important to change our validation artefacts to avoid using a special schematron xslt. If implementers use the standard ISO artefacts, several rules will not fire, and invalid instance documents will be sent. My suggestion is to fix this in the TC434 artefacts, to ensure users can use the standard ISO schematron files.

[SiwMeckelborg]

The [@Attribute] will work, we have used that for some EHF validation, but after discussions with Ken Holman of OASIS, he informed that it would be much better to add the different elements in the context, as the example I showed in my comment: <rule context="cbc:Amount | cbc:BaseAmount | cbc:PriceAmount >

[phax]

There are too many types that can contain an Amount currency (this is A to M):

[SiwMeckelborg]

We do not use all these in the spec, so the check can be written as follows:

     <rule context="cbc:Amount | cbc:BaseAmount | cbc:PriceAmount | 
    cac:TaxTotal[cac:TaxSubtotal]/cbc:TaxAmount | cbc:TaxableAmount | 
    cbc:LineExtensionAmount | cbc:TaxExclusiveAmount | cbc:TaxInclusiveAmount | 
    cbc:AllowanceTotalAmount | cbc:ChargeTotalAmount | cbc:PrepaidAmount | 
    cbc:PayableRoundingAmount | cbc:PayableAmount">

[oriol]

There are other rules that contain an attribute in the context. Not only currencyID...

[SiwMeckelborg]

There are 3 rules for EN16931, thats all

[oriol]

  <rule context="@currencyID" flag="fatal">
  <rule context="cac:AdditionalDocumentReference[cbc:DocumentTypeCode = '130']/cbc:ID/@schemeID | cac:DocumentReference[cbc:DocumentTypeCode = '130']/cbc:ID/@schemeID" flag="fatal">
  <rule context="cac:PartyIdentification/cbc:ID/@schemeID" flag="fatal">
  <rule context="cbc:CompanyID/@schemeID[not(ancestor::cac:PartyTaxScheme)]" flag="fatal">
  <rule context="cac:CommodityClassification/cbc:ItemClassificationCode/@listID" flag="fatal">
  <rule context="cac:StandardItemIdentification/cbc:ID/@schemeID" flag="fatal">
  <rule context="@unitCode" flag="fatal">
  <rule context="@mimeCode" flag="fatal">

[SiwMeckelborg]

My mistake.

I think the rules where it is not only the attribute, can easily be rewritten to use the predicate [@Attribute] , or move the attribute from the context to the test.

[klakegg]

I don't see a change to Schematron being provided anytime soon, and after that you have a lot of tools that need to update something they've never updated before. Also I think the lack of support for addressing attributes in contexts is by design, because fixing the visiting part results in another problem related to the reported path of the assert.

I think it is more important to make sure the rules provided by TC434 works with what we have in Schematron today and not something we potentially may have in the future, and potentially even further into the future have updated tools.

[phax]

This is a bug in the Schematron release and not in the Validation artefacts. So please force them to solve the issue - I don't see a problem at our side.

[SiwMeckelborg]

In my opinion, I don't think the discussion should be if this is a bug in Schematron or not. TC434 publishes validation artefacts that will be used by a large number of communities, and I find it very unfortunate to publish artefacts that need a special version of the Schematron stylesheets. The workaround for TC434 is quite simple, it is a small change in 8 of our rules, and then the ISO version can be used.

[phax]

Please go ahead and make a PR - we will than cross-check it. Does that sound reasonable?

[klakegg]

PR provided - it's time to accept the update.