Semanticmediawiki: Use of escape sequences in template output poduces different results (sep= ...)

[Contrafibularity]

Setup and configuration

• SMW version: 2.5rc
• MW version: 1.28
• PHP version: 5.6.30-0+deb8u1 (apache2handler)

Issue

See https://sandbox.semantic-mediawiki.org/wiki/Issue_with_double_sep_in_template_format

When used with the template format, sep is intended to delimit the property values that are passed to the template. However, in the first example provided on the sandbox page, it also ends up delimiting the results (hence the semi-colon), which I assume is a (recent) bug.

I'm not sure what the cause is though I suspect that it may have something to do with the number of prinouts parameters used by the template.

[mwjames]

There was a fix for sep (#2022, #2090) which produces the expected results but the MediaWiki Parser is working its magic which can be seen when we not use #ask and instead simply add the templates manually [0] (this involves no SMW).

{{Show example for normal sep|1=CityA|?Page=CityA|?Capital of=CapitalA|#=0|userparam=Test test}};{{Show example for normal sep|1=CityB|?Page=CityB|?Capital of=CapitalB|#=1|userparam=Test test}};{{Show example for normal sep|1=CityC|?Page=CityC|?Capital of=CapitalC|#=2|userparam=Test test}}

{{Show example for double sep|1=CityA|?Page=CityA|?Capital of=CapitalA|#=0|userparam=Test test}};{{Show example for double sep|1=CityB|?Page=CityB|?Capital of=CapitalB|#=1|userparam=Test test}};{{Show example for double sep|1=CityC|?Page=CityC|?Capital of=CapitalC|#=2|userparam=Test test}}



md5-91782558261741799cf0206a3cb1225e



<includeonly><div>[[{{{?Page|}}}]] </div></includeonly>



md5-da321a866baed6fbeed99d7f9ea6f7f5



<includeonly>


md5-6dfabdc91b75b7bb1847f6818229bcbb


</includeonly>

[0] https://sandbox.semantic-mediawiki.org/wiki/Issue/2329

[mwjames]

Before 2.5 the sep would not be published but #2022 fixes that so that the content returned to MW would now correctly contain {{Template| ...}} sep {{Template|...}} sep .... As demonstrated above, MW is using a different schema to generate the final output depending of how escape sequences \n (newline) are used within those templates.

SMW is only involved in generating the template content (not the parsing) with the output and parsing being done by MediaWiki alone.

[Contrafibularity]

Thanks for clearing that up - I forgot about that particular MW-specific usage of semi-colons, so that explains.

Before 2.5 the sep would not be published but #2022 fixes that

This is then where I seem to be running into a good deal of trouble since this new behaviour interferes with my current setup. The sep used to separate values is mostly different from the sep used to separate query results/template instances (typically empty, in my case). How can we achieve that with SMW 2.5?

[mwjames]

new behaviour interferes with my current setup.

The behaviour has been corrected so that it would work as any other result printer.

• https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/2022#issuecomment-266207046
• Issues with the "sep" function in mode Query template.
• http://naruto.wikia.com/wiki/Thread:217742#29

The sep used to separate values is mostly different from the sep used to separate query results/template instances (typically empty, in my case). How can we achieve that with SMW 2.5?

Not sure what you mean, if you don't want a sep then leave the parameter empty and for all other cases sep is added as one would expect.

How can we achieve that with SMW 2.5?

What is the use case?

[Contrafibularity]

I've grown accustomed to using sep as a delimiter for every array of property values that the template takes on to process further (usually involving use of #arraymap or #arraydefine); not as a delimiter for every new instance of a template.

Maybe introduce manysep, to borrow the term from the Arrays/Hash result formats?

[mwjames]

I've grown accustomed to using sep as a delimiter for every array of property values that the template takes

@kghbln Some input or suggestions here would be appreciated. It is very unlikely that #2022 gets reverted (for the cited reasons) therefore I'm looking for a different proposal (e.g. add new innersep parameter or similar suggestions).

[mwjames]

I've been thinking about this for a bit and #2331 adds the $smwgResultFormatsFeatures setting which allows to attach SMW_RF_TEMPLATE_OUTSEP as flag (and is set by default) to support above described behaviour with an additional valuesep parameter (separator for an inner multiple value list) to avoid ambiguity of the sep parameter semantics.

To retain the 2.4 behaviour, the following setting can be used $GLOBALS['smwgResultFormatsFeatures'] = ( $GLOBALS['smwgResultFormatsFeatures'] & ~SMW_RF_TEMPLATE_OUTSEP );

[Contrafibularity]

Thanks for checking in what I think is a sensible solution! It restores consistency to the use of sep in multiple format contexts (template, list, etc.) while additionally allowing us to separate values using what is now called an innersep.

[jaideraf]

@mwjames If I understand, this bug correlates with this one: https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/316

In general, the possibilty to especify a sep for properties and a sep for values (of the same property).
So, the bug described here reminds me the (third) sep for instances (subjects or subobjetcs).

I am not sure if am helping the understanding or complicating it. :wink:

[mwjames]

If I understand, this bug correlates with this one: #316

In a very wide proximity, yes but the described behaviour here is limited to format=template.

It restores consistency to the use of sep in multiple format contexts (template, list, etc.) while additionally allowing us to separate values

It doesn't restore "consistency". I added the setting to avoid for users to have a "hard" landing due to changes in 2.5 and some inconsistencies with the sep parameter (I have given related links as to why those are inconsistencies).

Let me try to explain again of what is expected. The following description is only for format=template and 2.5 (with the flag SMW_RF_TEMPLATE_OUTSEP being enabled by default):

• sep is used for the outer separation of value content as in {{Template| ...}} sep {{Template|...}} sep ...
• valuesep is provided as additional parameter to allow for multiple values within {{Template|...}} to be separated

If you want to retain the behaviour before 2.5 (of which was broken since ... ?) then I suggest using $GLOBALS['smwgResultFormatsFeatures'] = ( $GLOBALS['smwgResultFormatsFeatures'] & ~SMW_RF_TEMPLATE_OUTSEP );