Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify specification of p:validate-with-schematron #17

Closed
xml-project opened this issue Nov 21, 2017 · 10 comments

Comments

Projects
None yet
4 participants
@xml-project
Copy link
Contributor

commented Nov 21, 2017

The current version of the specs says:

The parameters option provides name/value pairs which correspond to Schematron external variables.

Does this mean, they are also passed to the final stage of processing, when the generated XSLT is applied to the document?

This issue was raised for XProc (1.0) before by @gimsieke, but the problem is not solved with the current version of the specs.

I propose to use the solution of XMLCalabash as standard, viz. pass the parameters also to stage 4 to make it accessible with <xsl:param />.

@gimsieke

This comment has been minimized.

Copy link
Contributor

commented Nov 21, 2017

I obviously agree with this suggestion.
We should state something like:

The supported Schematron versions and extensions are implementation-defined. An implementation that supports p:validate-with-schematron must support at least ISO/IEC 19757-3:2006 with the XSLT2 query bindings. If the Schematron schema is in the namespace http://purl.oclc.org/dsdl/schematron (ISO Schematron) and its queryBinding attribute is xslt2 (case insensitive), and if foreign markup is allowed in the Schematron schema by virtue of the allow-foreign parameter, the step must supply all parameters to all implementing stylesheets and to the generated stylesheet as xsl:param elements. Only the phase parameter will be taken from the step’s phase option. A supplied parameter named phase must be ignored [or raise an error?].

@xml-project

This comment has been minimized.

Copy link
Contributor Author

commented Nov 22, 2017

I wonder whether we should make a difference between parameters passed to schematron building (phase 1-3) and parameters passed to the actual validation (phase 4). This could be helpful to avoid confusion with names reserved for schematron.

If we want to do this, I see three options:
(a) provide a second map on p:validate-with-schematron with parameters for phase 4.
(b) require parameters for phase 1-3 to be in schematron's namespace
(c) require parameters for phase 4 to be in a namespace (no XProc namespace, no schematron-namespace)

I would opt for (b): A parameters in schematron's namespace is supplied to phase 1-3 as an NCName. All other parameters are supplied to phase 4.

@gimsieke

This comment has been minimized.

Copy link
Contributor

commented Nov 22, 2017

We should be careful not to focus on that single Schematron implementation (unless we define the step in terms of specific XSLT transformations, see below).
On the one hand I’ve suggested that the default ISO Schematron XSLT2 implementation must be supported by each XProc processor. On the other hand, we should not assume that every Schematron implementation takes this multiple-step XSLT approach.

If we define p:validate-with-schematron in terms of an XProc pipeline (that orchestrates the standard XSLT2 stylesheets) rather than as an opaque step, we can assume that the XSLT-generating process accepts a defined set of parameters, such as allow-foreign and full-path-notation. Then we can also pass them as options, like phase.
(There are other steps that may implemented as XProc pipelines, for example the recursive directory listing, but also p:add-attribute, p:delete, p:string-replace, etc. Many of them can be implemented with p:xslt.)
But I wouldn’t suggest that we do so.

Another consideration is: Will Schematron schema authors use the “reserved” params such as allow-foreign anyway in their schemas? Isn’t it confusing for them if they can pass both sch:allow-foreign and allow-foreign to the step? They probably won’t, but there’s also a property param in the default implementation that triggers support of the property element that was introduced in ISO Schematron 2016. It is more likely that someone already uses a property param in their Schematron schemas than that they use an allow-foreign param. Therefore I think suggestion (b) is alright and future-proof. We should say that for the default XSLT2 ISO implementation that must be supported, processors must pass the sch- (http://purl.oclc.org/dsdl/schematron-) prefixed params (only) to the XSLT-generating stylesheets, as unprefixed params, and they must pass all other params (only) to the generated stylesheets.

Another note: If we stipulate that all processors support the XSLT2 ISO implementation, we should allow them to support newer and extended versions of this implementation. An extended version, for example, is oXygen’s abstract pattern implementation. There you can have parameterized patterns that accept, for ex., $severity as a parameter and use it in the @role attribute, for ex. <report test="$size-in-mb &gt; $max" role="$severity">. You cannot use parameters for @role in the default XSLT2 ISO implementation. Likewise, implementations should be free to use XSLT 3.0 features even though the query binding is xslt2. Extensions to the baseline XSLT2 ISO implementation should be implementation-defined.

@xml-project

This comment has been minimized.

Copy link
Contributor Author

commented Nov 22, 2017

@gimsieke do you really want to say, that the default ISO Schematron XSLT2 implementation must be supported?
I would, as in other cases, refer to the standard which is the step supposed to implement. But of course I am not an expert in schematron as you are.

Therefor your are of course right that we should distinguish between params controlling the behaviour of schematron and params controlling the schema and not talk about phases.

@gimsieke

This comment has been minimized.

Copy link
Contributor

commented Nov 22, 2017

The Schematron spec is quite unspecific on things that people have come to rely on because most people use the default implementation. But I heard people ask for non-XSLT implementations, and there are in fact non-XSLT implementations.
Switching on foreign vocabulary in order to be able to use xsl:function, xsl:value-of, or HTML markup in the SVRL is probably the most common thing. But allow-foreign is a parameter of the default stylesheets. Therefore it makes sense to stipulate that this default implementation be available.
Maybe we can handle it similarly to p:compare’s method option: We can have a QNamed option on p:validate-with-schematron called implementation, and the only mandatory implementation that each XProc processor must support is 'ISO-xslt2'.
If the XProc processor also provides ph-schematron’s XPath-based implementation, people can select ph-schematron-xpath for the implementation option, and then they’ll have a different set of sch-prefixed parameters available (and probably no meaningful non-prefixed parameters at all, because AFAIK the XPath implementation does not allow parameters to be passed to the bound schema).

@xml-project

This comment has been minimized.

Copy link
Contributor Author

commented Nov 22, 2017

Thank you very much. I think your argumentation is very convincing and we should follow the path you have sketched.

However I am not sure about a detail you suggested with the "method"-option. Is necessary to provide a mechanism to change the used Schematron-implementation on the fly from within a pipeline.
I think we should leave this aspect to the configuration process of an implementation.

@gimsieke

This comment has been minimized.

Copy link
Contributor

commented Nov 22, 2017

Ok, I think a configuration option will do for p:validate-with-schematron. This is different from the p:compare case insofar as the Schematron schema, by means of its namespace and the @queryBinding attribute, already gives a hint which implementation to use. That is, if users supply a schema that requests an XPath query binding, they already know that setting the param sch:allow-foreign='true' won’t probably effect their <xsl:value-of select="$somevar"/> to be allowed and evaluated.
(People use xsl:value-of instead of sch:value-of because, probably out of sloppiness, Schrematron does not allow sch:value-of inside sch:span, but people use sch:span elements for classification of messages, something that may now be provided by the property element that was introduced in ISO Schematron 2016 and that may be supported by the default stylesheets yet is flagged as an error in oXygen.)

And if someone wants to use, for example, a tweaked XSLT2 Schematron implementation (like oXygen’s for parameter expansion in role attributes), they can roll their own step.

@xml-project

This comment has been minimized.

Copy link
Contributor Author

commented Feb 7, 2018

As for Prague 2018 we proposed to use one map with one magic key "p:configuration" (or probably c:configuration) having another map which goes to the construction phase.
But this is only a consensus until Ari had talked to Andrew.

@xml-project xml-project removed their assignment Apr 4, 2018

@ndw ndw transferred this issue from xproc/3.0-specification Nov 1, 2018

@AndrewSales

This comment has been minimized.

Copy link

commented Feb 13, 2019

Some time later...

I just noticed this: can the signature here use #DEFAULT instead of #ALL?
If no default phase is given in the schema (configured externally using #DEFAULT), then all patterns (#ALL) are active.
If the default value of this option is #ALL and their schema specifies a defaultPhase then the user has to set the desired default twice, once in the schema and again in the pipeline processor, in order to override the, err, default.

@ndw

This comment has been minimized.

Copy link
Collaborator

commented Jun 11, 2019

Overetaken by events; this is now in the validation spec.

@ndw ndw closed this Jun 11, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.