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

Standard command-line options to help swapping #77

Open
rjelliffe opened this issue Aug 14, 2024 · 3 comments
Open

Standard command-line options to help swapping #77

rjelliffe opened this issue Aug 14, 2024 · 3 comments

Comments

@rjelliffe
Copy link
Member

Proposal
A new non-normative annex should be provided. An implementation can support the following command-line options, which take an ID argument:

  • Select/Deselect phase F - one phase is active at a time, also allowing #DEFAULT or #ANY
  • Activate/Deactive pattern P
  • Enable/Disable rule R - id of rule. The rule context is still evaluated, except for disabled rules at the end of the pattern, but none of its assertions and reports are tested. So there is no change in the results of other non-disabled rules in the pattern.
  • Enable/Disable assertion/report A

Other options (for parameters) should be provided.

The purpose of this to allow better swappability of different implementations. For example, so that a Schematron schema can generate a pop-up dialog box with checkboxes for all phases, patterns, rules and assertions to allow the user to enable or disable, and so that then this enabling/disabling can easily be transferred to the engine. (Whether implementers do it by a run-time test or compile-time test or by text pre-processing of the schema is implementation-specific.)

These commands should be provided also as URNs, (for example, these might be properties set on a Java validator object factory.)

This will help new implementers know the kind of thing their implementation should provide, and especially may help allowing swapping out of one implementation for another.

@AndrewSales
Copy link
Collaborator

This is for implementers to decide, and doesn't belong in the standard, in my view.

@rjelliffe
Copy link
Member Author

Yes it does belong in the body of a standard. It is presumably the thing that might be better in a TR rather than a non-nrmtve annex. And maybe there are not enough implementations to mean co-ordination is overkill.

@dmj
Copy link
Member

dmj commented Sep 2, 2024

I agree with @AndrewSales here: This is something that implementers should agree upon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants