-
Notifications
You must be signed in to change notification settings - Fork 0
general home
This page lists some general clarifications an minor enhancements to the Schematron standard.
Issue(s): #21
Description: It is unclear how a Schematron processor should resolve a relative value for the pattern/@documents attribute.
Proposed resolution: Change the text of specification section 5.4.10 to:
The optional documents attribute provides IRIs of the subordinate documents the rule contexts are relative to. If the expression evaluates to more than one IRI, then the pattern is sought in each of the documents. Relative IRIs are resolved to the base IRI of the original instance document. The documents attribute is evaluated in the context of the original instance document root.
All documents being validated are constant: i.e., they are the same for each pattern. Therefore if more than one patterns have the same IRI, the document should be retrieved once only.
Issue(s): #20
Description:
The <title> and <p> Schematron elements have different models for no directly apparent reason.
- The
<p>element follows the usual rules for mixed text in Schematron. It allows foreign attributes/elements and<dir>,<span>and<emph> - The
<title>element only allows<dir>and does not allow foreign attributes/elements.
Proposed resolution:
Define <title> the same as the current definition of <p>.
Description:
The standard is unclear about where exactly abstract pattern parameters are expanded and where not. There are two main issues:
- Should abstract pattern parameters expand in queries of properties and diagnostics?
- Should abstract pattern parameters expand in texts (and non-query attributes)?
Proposed resolution:
This needs to be discussed. First thoughts and considerations in #19.
Issue(s): #18
Description:
Section 3.13 of the 2020 specification reads:
pattern unordered collection of rules (3.18) with an optional identifier and ancillary information
This is add odds with section 6.5 clause 4 and 5. The order of rules in a pattern does matter.
Proposed resolution:
Change section 3.13 to
pattern ordered collection of rules (3.18) with an optional identifier and ancillary information
Issue(s): #17
Description:
Proposed resolution:
Issue(s): #13
Description:
The standard is unclear about which variables are in-scope when a property or diagnostic is expanded.
Proposed resolution:
Define that the following variables are in-scope when a property or diagnostic is expanded:
- All variables that are lexically in-scope.
- Variables in-scope in the assert or report that causes the expansion.
Issue(s): #12
Description:
The flag attribute of an assert or report is now typed as an xs:string in the Schematron RelaxNG schema. The specification calls it a "boolean variable" (singular). There are two issues:
- Since a flag is supposed to be the name of a variable, wouldn't it be better to restrict its data type to something more appropriate?
- Why not allow multiple flags to be raised?
Proposed resolution:
Change the data type of the flag attribute to list of xs:NCName. This allows multiple flags to be specified and restricts it to what is, in the XPath world, an (unqualified) variable name.
Adjust what is currently section 5.5.5.
Issue(s): #9
Description:
The specification leaves open whether a rule included using a <extends href="..."/> must be abstract or not.
Proposed resolution:
Given that a rule that is included this way is always an abstract rule (since it is included using the <extends> element), an included rule must be defined as abstract (has a mandatory abstract="true" attribute).
Add this additional constraint to what is currently section 5.4.4.
Issue(s): #2
Description:
Proposed resolution: