Define whether parameters in abstract patterns are expanded in messages also about schematron-enhancement-proposals HOT 6 CLOSED

I think the wording of the standard is clear: any query (ie every xpath) should be expanded. David asks a good question: why would you want to expand the xpath in assertions and diagnostics? One answer is that you may want to provide specific text. (writing away from computer, apologies if syntax is wrong) <pattern abstract="true" id="deferred-container"> <rule context="$parent"> <assert test="$child>A <value-of select="$top"/> should not have any <value-of select="$description"/>.</assert> </rule> </pattern> ... <pattern is-a="deferred-container" id="tables"> <param name="parent" value="tr" /> <param name="child" value="td" /> <param name="top" value="'spreadsheet'" /> <param name="description" value="'empty row''" /> </pattern> <!-- See https://en.m.wikipedia.org/wiki/XML/EDIFACT#Example_2:_XML/EDIFACT_source_code --> <pattern is-a="deferred-container" id="edifact-address"> <param name="parent" value="S_NAD/C_C059" /> <param name="child" value="D_D042" /> <param name="top" value="'Edifact address'" /> <param name="description" value="'the street and number''" /> </pattern> In both these cases, the element names are not clear enough to make an effective assertion text: and perhaps not the diagnostic either. The human recipient of the message may not have any awareness of the element names or Edifact codes. Further, the interesting element to establish context (really the "subject") is neither the @context nor the @test. *Localized* Additionally, consider when we have a multi-lingual version of the second pattern. There are several approaches: off the top of my head, one us probably to make a top-level variable "$subs" with <substitutions> <locale is="en"> <term code="S_NAD" value="'Edifact address'" /> <term code="street" value="'street and number'"/> </locale> ... </substitutions> <pattern abstract="true" id="deferred-container-localized"> <rule context="$parent"> <assert test="$child>A <value-of select="$subs/substitions/locale[@is = '$locale']/term[@code='$top-key']/@value"/> should not have any <value-of select="$subs/substitions/locale[@is = '$locale']/term[@code='$description-key]/@value"/>.</assert> </rule> </pattern> and pass the abstract pattern the key of the string <pattern is-a="deferred-container" id="edifact-address-localized"> <param name="parent" value="S_NAD/C_C059" /> <param name="child" value="D_D042" /> <param name="top-key" value="S_NAD'" /> <param name="description-key" value="street" /> </pattern> Another approach is for the abstract pattern to store the param value (raw or looked up) in a scoped variable, then have that available to the diagnostics and properties. *Intent* So the intent is that the user of an abstract pattern should be able to pass through information for populating the assertion's text, variables, diagnostics and properties. Abstract patterns should not be just a macro for @context and @rule: I think we should avoid the situation where if you use an abstract pattern, you lose the ability to make dynamic, rich assertion texts, diagnostics and properties. Does this make sense? Cheers Rick

OK, some better info. I misunderstood the question and answer as being the scope of replacement between ISO (I mean the standard) and SchXslt, but it is really a bug report on the skeleton code. In https://github.com/Schematron/schematron/blob/master/trunk/schematron/code/iso_abstract_expand.xsl we see the problem: <!-- Experiment: replace macros in text as well, to allow parameterized assertions and so on, without having to have spurious <iso:value-of> calls and multiple delimiting. NOTE: THIS FUNCTIONALITY WILL BE REMOVED IN THE FUTURE. -->

Yes. If you want a parameter-supplied value in a diagnostic, that is what sch:value-of is provided for. If the context of this is to provide xslt3 style {} evaluation, then I think the xslt3 only provides them on attribute values not elements, which I presume would be followed. Rick