Problem with SI-UBL 1.2 validation rules - attribute context

[phax]

Hi all, @ThijsFTW identified a gap in validation of the SI 1.2 rules, depending on the validation engine used. All of this is reported at https://github.com/phax/phive-rules/issues/9 The main explanation is in this sub-post: https://github.com/phax/phive-rules/issues/9#issuecomment-912417797

It would be great, if you could fix this in the old SI rules, and check that the SI-2.0 rules don't have similar issues.

Thanks :)

[tjeb]

The suggested fix in and of itself isn't good, as the rules would then match any element that has a currencyID, and not the currencyID attribute node itself (thereby potentially exluding those nodes from later checks).

And I may be wrong of course, but isn't this really a bug in the validation engine? An attribute is a node, and is selectable by an xpath expression such as those in context attributes. I don't have the latest version of the schematron specification readily available now that it got ISO-paywalled, but AFAIK it did not put any limitations on the types of selectable nodes in the context expression.

[phax]

@tjeb thanks for the swift response.

I had created copies of the previous spec versions - you can find them at https://github.com/phax/ph-schematron/tree/master/docs

The interesting link in the source issue points to Stack Overflow: Source: https://stackoverflow.com/a/28305335/15254

The problem with your current approach is that the template matching the attribute/s is never applied. It isn't applied, because the built-in template rule matches only the root node and element nodes, and it applies templates only to children nodes. To apply a template to attributes, you must apply it explicitly yourself.

This points to the XSLT 2.0 spec: https://www.w3.org/TR/xslt20/#built-in-rule

When a node is selected by xsl:apply-templates and there is no template rule in the stylesheet that can be used to process that node, a built-in template rule is evaluated instead.

The built-in template rules apply to all modes.

The built-in rule for document nodes and element nodes is equivalent to calling xsl:apply-templates with no select attribute, and with the mode attribute set to #current. If the built-in rule was invoked with parameters, those parameters are passed on in the implicit xsl:apply-templates instruction.

Reading on, what "xsl:apply-templates with no select attribute" means: https://www.w3.org/TR/xslt20/#element-apply-templates

The default value of the select attribute is child::node(), which causes all the children of context node to be processed.

And finally the "node()" function is described at https://www.w3.org/TR/xslt20/#pattern-examples

node() matches any node other than an attribute node, namespace node, or document node.

Hence, the default XSLT template processing does not include attribute nodes.

I agree, that my proposed resolution is eventually not ideal - but the general problem remains the same. Maybe you can place the assertion in an all the places where you need them, but using an attribute as a selector is not a general purpose solution imho.

[tjeb]

Luckily we have a few months until the next release cycle... there's other attributes that are used as selectors as well

But does this mean the Schematron (2016) specification is unimplementable, or is this only a limitation of some implementation choices? Annex H point 2 clearly states a rule context rules may be attributes.

[phax]

Sorry I found no time yet, to properly respond to this, but I want to. My assumption is, that this is exactly the "magic" in the boilerplate code, the XSLT implementations create....

[tjeb]

and suddenly the next release is not far away at all anymore.

I think I have a solution for this (and the related issue that the currency check was too wide-sweeping anyway), pushed in the branch above.

One note though; there are other places where an attribute is used in the context selector (some of them in code we originally got from the peppol bis v2 group), going over all of them and finding potential overlapping context matches may be too much work for 1.2.

It's not phased out yet, but it will be made optional for receivers soon, so it should then only be in use by parties that were already (successfully) using it and have not been able to move to 2.0 or PB3 yet.