-
Notifications
You must be signed in to change notification settings - Fork 0
additions home
This page lists ideas for more far-reaching additions and enhancements to the Schematron language. Some of these will break the compatibility with the current or previous versions.
Description:
The 'Introduction' in Schematron 2016 includes:
Considered as a document type, a Schematron schema contains natural-language assertions concerning a set of documents, marked up with various elements and attributes for testing these natural-language assertions, and for simplifying and grouping assertions.
The ability to write natural-language assertions is a key feature of Schematron. However, the natural-language assertions are written into an XML document, which is an unnatural language to many subject matter experts.
If there is a textual format for Schematron, that could reduce the cognitive load for subject matter experts who are not already familiar with XML and who have limited or no experience with angle brackets, matching start and end tags, or attribute syntax.
Proposal:
#22 has currently resulted in two proposals:
- Textual format for Schematron that is interchangeable with the XML format, similar to how the Relax NG compact syntax is interchangeable with the Relax NG XML format
- Spreadsheet for capturing the information to be included in the Schematron in a format that is likely to be quite familiar to subject matter experts
Issue(s): #16
Description:
Proposal:
Issue(s): #15
Description:
Proposal:
Issue(s): #14
Description:
Proposal:
Issue(s): #11
Description:
Parameters in abstract patterns use the same syntax as variable references: $name. However, they're not variables, they're macros that are expanded as text, as simple strings, inside expressions. Using the same syntax as variables is confusing and potentially leads to weird naming conflicts (what if there's a variable with the same name?).
Proposal:
There are two obvious ways to change this. Both are incompatible with the current Schematron version:
- Change the syntax for the abstract pattern parameters. For instance, use a different first symbol, like
#nameor%name. - Re-define the whole mechanism for abstract pattern parameters, so that these parameters become real XPath variables instead of macro-expanded strings. See Change abstract pattern mechanism below.
Issue(s): #8
Description:
There is no way you can define which parameters are there for an abstract pattern. Therefore the processor cannot check that an abstract pattern invocation is correct.
Proposal:
There are two obvious ways to change this. Both are incompatible with the current Schematron version:
- Make declaring abstract pattern parameters mandatory. Add some syntax for this to the language. For instance a
<sch:uses-parameter name="..."/>element. - Re-define the whole mechanism for abstract pattern parameters, so that these parameters become real XPath variables instead of macro-expanded strings. See Change abstract pattern mechanism below.
Issue(s): #29
Description:
This proposal tries to deal with two issues:
- Abstract pattern parameters behave as (are) macro-expanded text strings. That deviates from the way XSLT (and other programming languages) work with parameters.
- There are many Schematron users that are also doing XSLT. However, the syntax for using parameters deviates in a confusing way from how XSLT is doing it. Schematron uses
<sch:param .../>to set a parameter. XSLT Uses<xsl:param .../>to define a parameter and<xsl:with-param .../>to set it.
Proposal:
- Make abstract pattern parameters XPath variables.
- Use the XSLT element names :
<sch:param .../>to define a parameter and<sch:with-param .../>to set them.
Issue(s): #3
Description:
Proposal:
Issue(s): #1
Description:
Proposal: