Last modified: 2011-08-07 18:35:53 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T32267, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 30267 - #smwdoc is inconsistent
#smwdoc is inconsistent
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Semantic MediaWiki (Other open bugs)
unspecified
All All
: Unprioritized minor with 1 vote (vote)
: ---
Assigned To: Markus Krötzsch
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-07 10:28 UTC by [[kgh]]
Modified: 2011-08-07 18:35 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description [[kgh]] 2011-08-07 10:28:47 UTC
Heiya, I have just seen this in action for the first time. It is awesome. However I would like to make a suggestion to make it even better:

The column "Default" generally shows the default value for the respective parameter except for the parameters "format" and "sep". There it shows "required" though in the first case it should show "table/list" and in the second ",". This is inconsistent. Thus I suggest adding another column called "Setting" which contains information about if the parameter is "required" or "optional" and to change the two entries in column "Default".

Cheers [[kgh]]
Comment 1 [[kgh]] 2011-08-07 13:51:23 UTC
Heiya, I used csv as an example. As far as I see the other result formats are treated alike. Cheers [[kgh]]
Comment 2 Jeroen De Dauw 2011-08-07 14:35:06 UTC
The format parameter should not be there at all, and has in fact been removed already in SMW 1.6.1 alpha. The sep parameter showing up as required is not a bug in the #smwdoc parameter, but one in the csv format. When using this format SMW 1.6.0, you will see it is in fact required, and you'll get an error when not providing it. This has been fixed in r94044.

I'm not sure I get your suggestion for changes to the columns. When a parameter has a default value, it's not required. So both the default value and indication the parameter is required can go into a single column w/o any overlap.
Comment 3 [[kgh]] 2011-08-07 15:21:09 UTC
Yeah, the format parameter may indeed be removed. In case "required" gets exchanged by "," for the parameter separator in column "Default", which was fixed in the meantime, then this is ok too. In this case you truly do not need an extra column indicating if it is compulsory to set a parameter or not.

However you insight into this matter points to a possible future regression when using formats. So far it was possible to use a format without setting extra parameters at all. All the default settings were automatically assumed an thus added. In case of the separator a comma was automatically assumed as the desired parameter value. If I understand correctly one now has to set the default values when using a format to avoid getting an error message. Thus I will have to go through all the inline queries to change them?
Comment 4 Jeroen De Dauw 2011-08-07 15:49:30 UTC
No, that would be rather bad :)

There is no regression whatsoever, next to the sep parameter in the csv format, which has now been fixed. When no value is provided, the default will be assumed. The difference with earlier versions is that the default is now specified in a declarative fashion, instead of being encoded in some arbitrary code of the format, making it actually possible to display the default value in #smwdoc, or on Special:Ask.
Comment 5 [[kgh]] 2011-08-07 18:23:10 UTC
All my worst fears have vanished now. :) Now I finally grasp some part of the difflink provided. This is very good news. One cannot beat the experts :)
Comment 6 Jeroen De Dauw 2011-08-07 18:32:34 UTC
> One cannot beat the experts :)

Sure one can; that's how innovation happens :)
Comment 7 [[kgh]] 2011-08-07 18:35:53 UTC
(In reply to comment #6)
> > One cannot beat the experts :)
> 
> Sure one can; that's how innovation happens :)

Ok ok, once again I was wrong. Let me be more precise then: I cannot beat the experts. :)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links