mricaud/xslt-quality

XSLT Quality

xslt-quality's Issues

Integrate @Arithmeticus evolutions

Integrate @Arithmeticus evolutions from PR #23, see commit Arithmeticus@e0cc349

Check namespace on fn:transform map

From @Arithmeticus on slack xml.com:

Lesson learned. If building a map for fn:transform() , as a habit put an xmlns="[target XSLT default XPath namespace]" in the appropriate xsl:map-entry, e.g.,
<xsl:map-entry key="'static-params'" xmlns="">
xsl:map
<xsl:map-entry key="xs:QName('diagnostics-on')" select="true()"/>
</xsl:map>
</xsl:map-entry>
(Heck, put it at the topmost xsl:map.) If you don't and if you're working in an XSLT file whose default namespace is bound to something else (e.g., HTML), that default NS will get attached to any unprefixed result of xs:QName() . Good chance your parameter bindings will be ignored. One more test worth adding to one's Schematron XSLT checker. (Note, the target default XPath namespace, /*/@xpath-default-namespace should not be confused with the target default namespace xmlns="...".)

Move rule "use-resolve-uri-in-loading-function" elsewhere cause it's too specific?

Parameters to let users control arbitrary thresholds

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?

Properly set localisation in schematron and SQF

Oxygen is complaining about errors with localisation messages.
We add support for french language in the documention, but not in the message or SQF title.

There must be ways to do that properly, and probably add external files for any localisation

Check that XSLT default templates are not used

Check that XSLT default templates are not used like:

<xsl:template match="/">
xsl:apply-template
</xsl:template>

Use XSPec tests for schematron and XSLT

XSpec can perform schematron and XSLT tests, this would be good to add it here for the main schematron and also for the xslt library.

Create a new repo for xslq:conf so it can be used with any schematron

This would probably involve to change the namespace, that's why it should be done before Release 1.0

Notes : use PI instead of ignore attribute, cf. https://www.linkedin.com/pulse/taking-schematron-quickfix-next-level-octavian-nadolu/?articleId=6602460611286716416

Release 1.0.0-RC2

Main issue for Release 1.0.0-RC2

• Issue #28 : localisation
• add ignore-role="info/warning/error" in the conf
• What about an "master files" attribute ?
• Dependency to xut for include resolutions
  • make xut more configurable
• Dependency to xslLib
  • publish xslLib to maven central
• Rename ids, add xslq as prefix everywhere + a simple name for assert/report
  • restructure modules / ids, it's a bit to complex and fix this for a long time
• Performance : improve (ex: xsl:output rule)

parsing the xsl as text

Writing:

That mean parsing the xsl as text here, something like:

<sch:let name="xslt.txt" select="unparse-text(base-uri(/))"/>

indent with spaces
No break line inside templates
Space around operators ( =, +, > etc)

Should the template ordering be watched by the schematron (copy template at the end, templates with @mode together, etc.)

Make any XSLT components of xslt-quality valid using xslq:conf

As a good practice, it would be nice any XSLT used in xslty-quality is valid according to xslt-quality itself :)

Using <xsl:value-of> where <xsl:sequence> is enough

Named template for generating XML elements VS functions to return atomic values as a good practice?

Check tunnel parameters

As said in https://xmlcom.slack.com/archives/C011NLXE4DU/p1601148109077300 a common mistake is to forget to declare tunnel parameters.
We could add a schematron warning when a parameter is thrown as tunneled and when the same name parameter is not delcared as tunneled in another template.

Unused templates, functions, global variables/parameters might not be an error (when the xsl is a library)

Check for conventions

https://google.github.io/styleguide/xmlstyle.html
http://blog.xml.rocks/xslt-naming-conventions
http://blog.xml.rocks/structuring-xslt-code

Release 1.0.0-RC1

Main issue for Release 1.0.0-RC1

Prerequisite

• Issue #21: add Xspec TU on schematron and XSLT
• Issue #5: add schematron quick fix
• Issue #27 : integrate @Arithmeticus evolutions
• Issue #22: Parameters to let users control arbitrary thresholds
  • to be finished : add missing parameters
• Issue #29 : make any XSLT components of xslt-quality valid
• Issue #30 : new repo for xslq:conf

Delivery

• Packaging zip, not jar to avoid confusion
• Update README
• Maven Central publication + add release zip to be download from github

Using template named "xsl:initial-template" results in warning

XLS-T 3.0 allows a transform to be run without an input document, when it contains a template named 'xsl:initial-template'.

This template gets called explicitly from outside of the stylesheet, via the processor's command line, therefore the warning, "[xslqual] Named template in unused the stylesheet", is redundant.

Add Schematron QuickFix

http://www.schematron-quickfix.com/quickFix/guide.html

Version 1.0.0-SNAPSHOT: restructure xslt-quality framework

After @Arithmeticus PR at #19
The global XSLT-quality framewrok actually needs to be restructured

This Issue will held commits for this work leading to a 1.0.0 version

xsl-qual : have a look at M. Kay's comments & suggestions on Mukul Ghandi rules

xsl-qual : have a look at comments on http://markmail.org/message/y5cunpvfpy54wqe6

validation problem with XSLT3

Hello,

I have a problem of validation the XSLT3 files with your schematron.
In a XSLT3, I declare some variables and functions and I call them between { }. The infomations in { } are not recognized by the schematron.
The error message is as follows:
[xslqual] Stylesheet function is unused

Qian