SMW Feature Request - Comparators: Difference between revisions

From SaruWiki
Jump to navigation Jump to search
(more layout updates)
m (... and yet more)
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
==Request==
==Request==
Please add the following new comparators: “less than” and “greater than”
Please add the following new comparators: "less than" and "greater than"


==Proposal==
==Proposal==
'''A]''' Redefine comparators < and > to fit their mathematical meaning: less than and greater than<br>
&nbsp;&nbsp;&nbsp;'''A]''' Redefine comparators < and > to fit their mathematical meaning: "less than" and "greater than"<br>
'''B]''' Add a new notation for the original comparators “less than or equal” and “greater than or equal”. The notation itself could either be the actual characters (Unicode 2264/Extended ASCII 243  ≤  and Unicode 2265/Extended ASCII 242  ≥ ) or their two-characterASCII approximations (<= and >=) or something else. People with knowledge of code pages and MW parsers may say something intelligent about this<br>
 
'''C]''' SMW might need a parameter for backward compatibility with the original < and > comparators: $smwComparatorOldBehaviour. Reason: if one already has a wiki and it uses < and >, the new style alters the behaviour of existing queries with < or >. Admins of these wikis could set $smwComparatorOldBehaviour=true. This would have the effect of disabling the new “greater than” and “less than” comparators, and the parser would treat both < and ≤ the same (“greater than or equal”), meaning the wiki could start using ≤ explicitly, eventually switching over  to the “new” behaviour once all existing queries are corrected. After setting $smwComparatorOldBehaviour=false, SMW would start parsing < as “less than” and ≤ as “less than or equal”. It can also be argued that the parameter should be named $smwComparatorNewBehaviour, or $smwUseGreaterThanAndLessThanComparators, etc. I propose the $smwComparatorOldBehaviour name, so that we can use it while we need, and in the future (e.g. in the year 2099) can declare the the parameter deprecated, when we believe that no wiki on earth runs in the counter-intuitive Comparator Old Behaviour mode.<br>
&nbsp;&nbsp;&nbsp;'''B]''' Add a new notation for the original comparators “less than or equal” and “greater than or equal”. The notation itself could either be the actual characters (Unicode 2264/Extended ASCII 243  ≤  and Unicode 2265/Extended ASCII 242  ≥ ) or their two-characterASCII approximations (<= and >=) or something else. People with knowledge of code pages and MW parsers may say something intelligent about this<br>
'''D]''' The backward compatibility parameter should get a default value. It can be argued that the default setting for $smwComparatorOldBehaviour should be
 
* false, so that from now on every new wiki is always in new behaviour while we still can accommodate admins of existing wikis (but there's an increased risk of incorrect queries when admins of existing wikis fail to set/correct the parameter);
&nbsp;&nbsp;&nbsp;'''C]''' SMW might need a parameter for backward compatibility with the original < and > comparators: ''$smwComparatorOldBehaviour''. Reason: if one already has a wiki and it uses < and >, the new style alters the behaviour of existing queries with < or >. Admins of these wikis could set ''$smwComparatorOldBehaviour=true''. This would have the effect of disabling the new “greater than” and “less than” comparators, and the parser would treat both < and ≤ the same (“greater than or equal”), meaning the wiki could start using ≤ explicitly, eventually switching over  to the “new” behaviour once all existing queries are corrected. After setting ''$smwComparatorOldBehaviour=false'', SMW would start parsing < as “less than” and ≤ as “less than or equal”. It can also be argued that the parameter should be named ''$smwComparatorNewBehaviour'', or ''$smwUseGreaterThanAndLessThanComparators'', etc. I propose the ''$smwComparatorOldBehaviour'' name, so that we can use it while we need, and in the future (e.g. in the year 2099) can declare the the parameter deprecated, when we believe that no wiki on earth runs in the counter-intuitive Comparator Old Behaviour mode.<br>
* true, so that correct querying for existing wikis is ensured (but there's a great risk of new wiki's not switching to the new behaviour)
 
* true for now, and false in a later version of SMW, to have people get used to the idea while not forcing anything.
&nbsp;&nbsp;&nbsp;'''D]''' The backward compatibility parameter should get a default value. It can be argued that the default setting for ''$smwComparatorOldBehaviour'' should be
* ''false'', so that from now on every new wiki is always in new behaviour while we still can accommodate admins of existing wikis (but there's an increased risk of incorrect queries when admins of existing wikis fail to set/correct the parameter);
* ''true'', so that correct querying for existing wikis is ensured (but there's a great risk of new wiki's not switching to the new behaviour)
* ''true'' for now, and ''false'' in a later version of SMW, to have people get used to the idea while not forcing anything.
I personally vote for the first option, with a clear warning in the release notes.
I personally vote for the first option, with a clear warning in the release notes.
   
   
==Background==
==Background==
As described in the Semantic MediaWiki online documentation, the SMW comparators are:
As described in the Semantic MediaWiki online [http://semantic-mediawiki.org/wiki/Help:Selecting_pages#Greater_than_or_equal.2C_less_than_or_equal documentation], the SMW comparators are:
* > and <: greater than/less than or equal
* > and <: greater than/less than or equal
* !: unequal
* !: unequal
* ~: «like» comparison for strings (disabled by default)  
* ~: «like» comparison for strings (disabled by default)  
This does not readily allow for disjunct selects. Example: suppose property “Foo” is of type number. Ideally, you would like to be able to select (with “mathematical” comparators instead of SMW comparators):<br>
This does not readily allow for disjunct selects. Example: suppose property ''Foo'' is of type number. Ideally, you would like to be able to select (with “mathematical” comparators instead of SMW comparators):<br>
'''a)''' <nowiki>[[Foo::< 10]]</nowiki> (less than 10)<br>
&nbsp;&nbsp;&nbsp;'''a)''' ''<nowiki>[[Foo::< 10]]</nowiki>'' (less than 10)<br>
'''b)'''  <nowiki>[[Foo::>=10]]</nowiki> (10 or greater)<br>
&nbsp;&nbsp;&nbsp;'''b)'''  ''<nowiki>[[Foo::>=10]]</nowiki>'' (10 or greater)<br>
However, since the first comparator does not exist, a strict disjunct selection under SMW looks like this
However, since the first comparator does not exist, a strict disjunct selection under SMW looks like this<br>
'''c)'''  <nowiki>[[Foo::< 10]][[Foo::!10]]</nowiki> (less than 10)<br>
&nbsp;&nbsp;&nbsp;'''c)'''  ''<nowiki>[[Foo::< 10]][[Foo::!10]]</nowiki>'' (less than 10)<br>
'''d)'''  <nowiki>[[Foo::>10]]</nowiki> (10 or greater)<br>
&nbsp;&nbsp;&nbsp;'''d)'''  ''<nowiki>[[Foo::>10]]</nowiki>'' (10 or greater)<br>
Technically this works, but the notation is counter-intuitive.
Technically this works, but the notation is counter-intuitive.


Furthermore, the fact that > is “greater than or equal” and not simply “greater than” can lead to unpleasant situations. Consider a property “maturity” with allowed values 1, 2, 3, 4, 5, and 9. When selection all values in the range 1-5, you must use <nowiki>[[Maturity::<9]][[Maturity::!9]]</nowiki> for “everything below 9”, instead of something like <nowiki>[[Maturity::<8]]</nowiki>, since 8 is (currently) not an allowed value; the notation inside a query would yield the famous yellow-exclamation-triangle.
Furthermore, the fact that > is “greater than or equal” and not simply “greater than” can lead to unpleasant situations. Consider a property ''maturity'' with allowed values 1, 2, 3, 4, 5, and 9. When selection all values in the range 1-5, you must use ''<nowiki>[[Maturity::<9]][[Maturity::!9]]</nowiki>'' for “everything below 9”, instead of something like ''<nowiki>[[Maturity::<8]]</nowiki>'', since 8 is (currently) not an allowed value; the notation inside a query would yield the famous yellow-exclamation-triangle.


Entered in Bugzilla under [https://bugzilla.wikimedia.org/show_bug.cgi?id=25418 ID 25418]
Entered in Bugzilla under [https://bugzilla.wikimedia.org/show_bug.cgi?id=25418 ID 25418]

Latest revision as of 20:56, 4 October 2010

Request

Please add the following new comparators: "less than" and "greater than"

Proposal

   A] Redefine comparators < and > to fit their mathematical meaning: "less than" and "greater than"

   B] Add a new notation for the original comparators “less than or equal” and “greater than or equal”. The notation itself could either be the actual characters (Unicode 2264/Extended ASCII 243 ≤ and Unicode 2265/Extended ASCII 242 ≥ ) or their two-characterASCII approximations (<= and >=) or something else. People with knowledge of code pages and MW parsers may say something intelligent about this

   C] SMW might need a parameter for backward compatibility with the original < and > comparators: $smwComparatorOldBehaviour. Reason: if one already has a wiki and it uses < and >, the new style alters the behaviour of existing queries with < or >. Admins of these wikis could set $smwComparatorOldBehaviour=true. This would have the effect of disabling the new “greater than” and “less than” comparators, and the parser would treat both < and ≤ the same (“greater than or equal”), meaning the wiki could start using ≤ explicitly, eventually switching over to the “new” behaviour once all existing queries are corrected. After setting $smwComparatorOldBehaviour=false, SMW would start parsing < as “less than” and ≤ as “less than or equal”. It can also be argued that the parameter should be named $smwComparatorNewBehaviour, or $smwUseGreaterThanAndLessThanComparators, etc. I propose the $smwComparatorOldBehaviour name, so that we can use it while we need, and in the future (e.g. in the year 2099) can declare the the parameter deprecated, when we believe that no wiki on earth runs in the counter-intuitive Comparator Old Behaviour mode.

   D] The backward compatibility parameter should get a default value. It can be argued that the default setting for $smwComparatorOldBehaviour should be

  • false, so that from now on every new wiki is always in new behaviour while we still can accommodate admins of existing wikis (but there's an increased risk of incorrect queries when admins of existing wikis fail to set/correct the parameter);
  • true, so that correct querying for existing wikis is ensured (but there's a great risk of new wiki's not switching to the new behaviour)
  • true for now, and false in a later version of SMW, to have people get used to the idea while not forcing anything.

I personally vote for the first option, with a clear warning in the release notes.

Background

As described in the Semantic MediaWiki online documentation, the SMW comparators are:

  • > and <: greater than/less than or equal
  • !: unequal
  • ~: «like» comparison for strings (disabled by default)

This does not readily allow for disjunct selects. Example: suppose property Foo is of type number. Ideally, you would like to be able to select (with “mathematical” comparators instead of SMW comparators):
   a) [[Foo::< 10]] (less than 10)
   b) [[Foo::>=10]] (10 or greater)
However, since the first comparator does not exist, a strict disjunct selection under SMW looks like this
   c) [[Foo::< 10]][[Foo::!10]] (less than 10)
   d) [[Foo::>10]] (10 or greater)
Technically this works, but the notation is counter-intuitive.

Furthermore, the fact that > is “greater than or equal” and not simply “greater than” can lead to unpleasant situations. Consider a property maturity with allowed values 1, 2, 3, 4, 5, and 9. When selection all values in the range 1-5, you must use [[Maturity::<9]][[Maturity::!9]] for “everything below 9”, instead of something like [[Maturity::<8]], since 8 is (currently) not an allowed value; the notation inside a query would yield the famous yellow-exclamation-triangle.

Entered in Bugzilla under ID 25418