Parameters to let users control arbitrary thresholds

[Arithmeticus]

Hi @mricaud I've done a pull, and I'm working on some improvements. I'm looking at the rule on granular templates, with a seemingly arbitrary value of 10. Who says that's too much or too little granularity?

With the new XSLT component for the Schematron, we let users decide themselves what threshold of granularity should be permitted. All that would be needed is to set up an XSLT file exclusively for user-controlled parameters. But where should it be put?

One could argue that it should be put at /src/main/sch/xsl/parameters/config.xsl. That would be consistent with the resources, but not very convenient for normal users, who usually dislike going so deeply into an arbitrary directory structure.

Another argument is to put it at simply parameters.xsl. That would allow users a way to quickly and easily change the configuration that is appropriate for their project without worrying about deep file structures. (In general, the higher up a file, and the fewer siblings, the better it is for a user to find and control what they should.) But it would mean that the main file at src/main/xsl/xslt-quality.xsl would need to have an element with several parent steps: <xsl:import href="../../../parameters.xsl">.

What do you think? Do you prefer one of these, or do you have a third suggestion?

[mricaud]

Hi @Arithmeticus

Just seen your message. The rule about granularity comes from Mukul Ghandi xsl-quality too : rule 11 TooManySmallTemplatesat http://gandhimukul.tripod.com/xslt/xslquality.html I just get it the same without changing anything. The arbitrary value of 10 templates comes from there, but I must admit I'm not convince by this rule. I have many XSLT with many templates, and I don't think this is quite a relevant error here. In the same way rule 12 MonolithicDesign is not always relevant : I sometimes have XSLT with only one template, used to override an imported XSLT.

My feedbacks:

1. I would maybe just delete those rules, but maybe making them configurable is a good alternativ.
2. As far as possible I guess the code should not been changed by the user, who should be rather able to call the code with parameters. Do you mean the parameters.xsl would just hold an <xsl:param> that people could override by calling the schematron?
3. Schematron doesn't allow parameter at high level (only within patterns), so I guess doing it within an imported XSLT is the good way to go. This is then an implementation problem : how to pass parameter to schematron. Jing doesn't allow this, so my collegues at ELSGestion adapted jing to support it (see this commit) But Oxygen doesn't allow to set a parameter to a schematron validation scenario.
4. I then don't see any possility to be avoid the user to change the code :( Maybe it could be an conf.xml file instead of parameters.xsl (conf.xml could be read by the xslt)

What are your feelings ?

[Arithmeticus]

Hi @mricaud -- I have personal style preferences on my quality, that make me want to have a variety of controls over where quality has scope. For example, I work in an environment where no namespaces are expected, and it's not up to me to change those rules. Also, I like to do documentation in a different way than with Oxygen's doc.

What about allowing the user to declare <xslq:parameters> within a given stylesheet? That element would have children elements corresponding to the global parameters, configuring the options. And once we get the Schematron Quick Fixes rolling, it should be easy for a user to add or remove these parameters as they like.

I've got a prototype that I'll try to patch together by tomorrow, so you can see. I'm also working on getting it set up so that the Schematron takes into account included and imported stylesheets, recursively.