nkutsche
commented
9 years ago Hi, thank you for your feedback! I see your problem, because I have it too. In SQF there are two options to do such multiple fixes for a list of possible parameter values:
Option 1: List of fixes for each item of the list If your list of parameter values (a and b in your example) is short and you know or define a maximum number of parameter items, you can define for each possible position a QuickFix. To hide the fixes, whose position is larger then the current item count, you can use the use-when condition. An example (from the sqf.sch which checks the rules of SQF):
<let name="asserts" value="../(sch:assert | sch:report)"/>
<let name="assertCount" value="count($asserts)"/>
<sch:assert test="..." sqf:fix="add">The fix is not used by any assert/report element.</sch:assert>
<sqf:group id="add">
<sqf:fix id="add1" use-when="$assertCount ge 1 and $assertCount le 3">
<sqf:description>
<sqf:title>Add a reference to the first of the assert/report elements.</sqf:title>
</sqf:description>
<sqf:add match="$asserts[1]" target="sqf:fix" node-type="attribute" select="
string-join((@sqf:fix,
$id), ' ')"/>
</sqf:fix>
<sqf:fix id="add2" use-when="$assertCount ge 2 and $assertCount le 3">
<sqf:description>
<sqf:title>Add a reference to the second of the assert/report elements.</sqf:title>
</sqf:description>
<sqf:add match="$asserts[2]" target="sqf:fix" node-type="attribute" select="
string-join((@sqf:fix,
$id), ' ')"/>
</sqf:fix>
<sqf:fix id="add3" use-when="$assertCount ge 3 and $assertCount le 3">
<sqf:description>
<sqf:title>Add a reference to the third of the assert/report elements.</sqf:title>
</sqf:description>
<sqf:add match="$asserts[3]" target="sqf:fix" node-type="attribute" select="
string-join((@sqf:fix,
$id), ' ')"/>
</sqf:fix>
</sqf:group>Pro:
- It show/hide dynamic the QuickFixes depending on the number of assert/report elements ($assertCount). If it is 1, only the first QuickFix will be shown - if it is 2, the first and the second, and so on... By coding a bit, you can rise the maximum number of QuickFixes as high as you want.
- you can add all fixes, by a single reference to the sqf:group (@sqf:fix="add").
Contra:
- you need to define a maximum of parameter items.
- This is very much and very similiar code for one thing. I opened a issue therefor (issue #2 ).
But: I don't think we should allow to generate unbounded QuickFixes for one Schematron error. This would causes many problems. So see option 2.
Option 2: Define User Entry (not supported in oXygen 17!) You can define a User Entry for that. So the user is able to set the needed parameter by itself, after the choose of the QuickFix:
<sqf:fix id="addGen">
<sqf:description>
<sqf:title>Add a reference to one of the existing assert/report elements.</sqf:title>
</sqf:description>
<sqf:user-entry name="pos" type="xs:integer" default="1">
<sqf:description>
<sqf:title>Please enter the position of the assert/report, which should refer to this fix.</sqf:title>
</sqf:description>
</sqf:user-entry>
<sqf:add match="$asserts[$pos]" target="sqf:fix" node-type="attribute" select="
string-join((@sqf:fix,
$id), ' ')"/>
</sqf:fix>The user defines the position of the assert, which should reference to the QuickFix, by setting the User Entry. Pro:
- this is now real generic, the list of parameter values could be unbounded
- it is short code
Contra:
- User Entries are not supported by oXygen 17
- At the moment, you can not define/generate an enumeration of possible values for the User Entry. Just the XSD data types are supported (theoretical).
My conclusion: I think the option 1 is for short parameter value lists acceptable. But I don't think it is very helpful, if a Schematron error has more than 10 QuickFixes. For larger parameter value lists, I think we should extend the User Entries, for instance like this:
<sqf:user-entry name="test">
<!-- ... -->
<sqf:type>
<sqf:enum select="distinct-values(//*/name())" base="xs:NCName"/> | <sqf:pattern pattern="{'\d\.\d\.\d\.'}"/>
</sqf:type>
</sqf:user-entry>But I think we should wait for an implementation, which support User Entries, before we extend this structure.
PStellmann
rvdb
octavianN
I've been experimenting with SQF to assist text editors with entering consistent regularizations for proper names in their XML documents. The idea is that there's an external file linking those regularizations with varying occurrences of the names; when an editor enters a name in an XML document, the value of that name is looked up in the regularizations list, and if a matching entry is found, a SQF should suggest to add the corresponding regularization in the XML file being edited. I'll make abstraction of the exact encoding details; the basic idea is that I want to use SQF to generate encoding suggestions from an open list of values, generated dynamically from some XPath expression.
This works well as long as only one value suggestion is retrieved. Yet, there are cases when multiple values (say "a" and "b") can be returned by the XPath expression. Currently, the most sensible option I've found is having one SQF offer a concatenation of all computed values for later disambiguation. Say, a single fix that offers something like: "add the value 'a|b' to your document". Later on, that concatenated value has to be cleaned up, and only the correct one should remain.
Yet, instead of concatenating those values in a single SQF suggestion, I'd like to be able to split them over separate SQF fixes, or to have one SQF generate multiple encoding suggestions. If values "a" and "b" are found, I'd like to offer two suggestions from which the text editor can choose:
If I understand the SQF syntax correctly, one SQF corresponds to a single suggestion, and each SQF has to be named explicitly in a @sqf:fix attribute Since the list of possible values is computed from a document (and not from, say, a closed value list in a schema), it is impossible to anticipate all possible values and create separate SQF'es in advance. I'm wondering if there is some kind of xsl:for-each concept that can be used to either generate separate suggestions in one SQF, or to generate separate SQF'es dynamically for each of the items in the iteration.