Define whether parameters in abstract patterns are expanded in messages also

[xatapult]

It is unclear whether parameters in abstract patterns should be expanded in message texts also. ISO does it, SchXslt (I tested version 1.7.2) doesn't.

[dmj]

My interpretation of the specs is that abstract pattern parameters are meant to be substituted in query language expressions only.

This is consistent with the following parts of the 2020 specification:

• The definition of the param element defines the @value attribute to contain "a fragment of a query" (5.4.9).
• A query language binding may optionally provide "a lexical convention such as a delimiter by which the parameters of abstract patterns inside query expressions shall be recognised" (6.4).
• The informative section about the minimal syntax in the 2020 specification describes the process of instantiation as "replacing
  parameter references with actual parameter values in all enclosed attributes that contain queries" (6.2).

I would also argue that replacing abstract pattern parameters inside the natural language assertion message is at odds with diagnostics in general and localized messages in particular.

[rjelliffe]

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

[rjelliffe]

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. -->

…

On Mon, 30 Aug. 2021, 21:32 David Maus, ***@***.***> wrote: > My interpretation of the specs is that abstract pattern parameters are > meant to be substituted in query language expressions only. > > This is consistent with the following parts of the 2020 specification: > > - The definition of the param element defines the @value > <https://github.com/value> attribute to contain "a fragment of a > query" (5.4.9). > - A query language binding may optionally provide "a lexical > convention such as a delimiter by which the parameters of abstract patterns > inside query expressions shall be recognised" (6.4). > - The informative section about the minimal syntax in the 2020 > specification describes the process of instantiation as "replacing > parameter references with actual parameter values in all enclosed > attributes that contain queries" (6.2). > > I would also argue that replacing abstract pattern parameters inside the > natural language assertion message is at odds with diagnostics in general > and localized messages in particular. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#10 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AF65KKJ6RSU4L77DMB5SP3TT7NT3TANCNFSM46NW4LEQ> > . > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. > >

[dmj]

I think there are two issues:

1. Should abstract pattern parameters expand in queries of properties and diagnostics?
2. Should abstract pattern parameters expand in texts (and non-query attributes)?

Re 1: @rjelliffe, you made a compelling argument to do so. We should clarify that. A good place to start would be the (informal) description of pattern instantiation.

Re 2: This would be an enhancement of the pattern templating mechanism.

[AndrewSales]

My interpretation of the specs is that abstract pattern parameters are meant to be substituted in query language expressions only. [...]
I would also argue that replacing abstract pattern parameters inside the natural language assertion message is at odds with diagnostics in general and localized messages in particular.

I agree with this view.

Should abstract pattern parameters expand in texts (and non-query attributes)? [...] This would be an enhancement of the pattern templating mechanism.

To keep things simple, clear and consistent, I would say the existing provision of value-of is enough.

A concise and effective change here might be to add a note to the definition of the term variable (3.23), e.g.

"Variables are represented in schemas by elements let and param."

The desired clarification then ripples through to value-of and also for property and diagnostic (by dint of the change made for #13).

This would also address #19.

[rjelliffe]

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

…

On Mon, 11 Mar. 2024, 23:50 Andrew Sales, ***@***.***> wrote: My interpretation of the specs is that abstract pattern parameters are meant to be substituted in query language expressions only. [...] I would also argue that replacing abstract pattern parameters inside the natural language assertion message is at odds with diagnostics in general and localized messages in particular. I agree with this view. Should abstract pattern parameters expand in texts (and non-query attributes)? [...] This would be an enhancement of the pattern templating mechanism. To keep things simple, clear and consistent, I would say the existing provision of value-of is enough. A concise and effective change here might be to add a note to the definition of the term variable (3.23), e.g. *"Variables are represented in schemas by elements let and param."* The desired clarification then ripples through to value-of and also for property and diagnostic (by dint of the change made for #13 <#13> ). — Reply to this email directly, view it on GitHub <#10 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF65KKJRU3TMK6R3PTZTAWLYXWR7XAVCNFSM46NW4LE2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJYHAZTMNZSG44A> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>