Last modified: 2010-03-28 15:13:08 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 T19142, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 17142 - OpenSearchXML extension resolves redirects in XML mode but not in JSON mode
OpenSearchXML extension resolves redirects in XML mode but not in JSON mode
Status: REOPENED
Product: MediaWiki extensions
Classification: Unclassified
OpenSearchXml (Other open bugs)
unspecified
All All
: Normal trivial (vote)
: ---
Assigned To: Brion Vibber
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-24 06:44 UTC by Ben Rimmington
Modified: 2010-03-28 15:13 UTC (History)
5 users (show)

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


Attachments

Description Ben Rimmington 2009-01-24 06:44:42 UTC
OVERVIEW DESCRIPTION:

The module that implements the OpenSearch protocol returns slightly different results in JSON and XML formats (for the same search string).

STEPS TO REPRODUCE:

1. http://en.wikipedia.org/w/api.php?action=opensearch&search=Neptune&limit=50&format=jsonfm
2. http://en.wikipedia.org/w/api.php?action=opensearch&search=Neptune&limit=50&format=xmlfm
3. Compare the results.

ACTUAL RESULTS:

The JSON results are in strictly alphabetical order. The XML results are in roughly alphabetical order -- redirections have been resolved, and duplicates have been removed.

e.g. The fifth JSON result "Neptune (astrology)" corresponds to the fifth XML result "Planets in astrology".

e.g. The sixth JSON result "Neptune (astronomy)" has been removed from the XML results as a duplicate.

e.g. The 43rd JSON result "Neptune Emerald" (which redirects to the "Neptune_Emerald#My-Otome_Zwei" section of the "Nina Wáng" page) has a corresponding XML result (but without the section anchor).

The JSON results contain 50 items (as requested). The XML results contain 35 items -- after redirections, 15 duplicates were removed.

EXPECTED RESULTS:

The JSON and XML results should be consistent with each other.

The action=query and action=parse modules support a "redirects" parameter -- perhaps action=opensearch should do the same?
Comment 1 Roan Kattouw 2009-01-24 11:48:56 UTC
Since action=opensearch is a prefix search, it shouldn't resolve redirects; tweaking summary accordingly.
Comment 2 Roan Kattouw 2009-01-24 12:05:13 UTC
Fixed in r46131
Comment 3 Brion Vibber 2009-01-26 22:58:30 UTC
Failing to resolve redirects leads to really crappy, ugly results -- much uglier with the text extract & thumbnail image than when doing a plain text results, where we never bothered to worry about it -- and it was very much done on purpose.

Reverted in r46295.
Comment 4 Gurch 2009-01-27 09:56:11 UTC
(In reply to comment #3)
> Failing to resolve redirects leads to really crappy, ugly results -- much
> uglier with the text extract & thumbnail image than when doing a plain text
> results, where we never bothered to worry about it -- and it was very much done
> on purpose.

...so in JSON mode it *should* resolve redirects? I think this bug was as much about the inconsistency between the two as anything else.
Comment 5 Roan Kattouw 2009-01-27 12:47:58 UTC
(In reply to comment #3)
> Failing to resolve redirects leads to really crappy, ugly results -- much
> uglier with the text extract & thumbnail image than when doing a plain text
> results, where we never bothered to worry about it -- and it was very much done
> on purpose.
>
I disagree. The OpenSearch module is supposed to be a prefix search. When typing in "Nept", a list in which everything starts with "Nept" and is sorted alphabetically is what you'd expect, not a list that has "Planets in astrology" in the middle of it (and hence isn't alphabetically sorted, because redirects are replaced in their slot).

(In reply to comment #4)
> ...so in JSON mode it *should* resolve redirects? I think this bug was as much
> about the inconsistency between the two as anything else.
> 
Also true. One of the two behaviors needs to be chosen as the 'right' one, and should be used consistently. REOPENing on this basis and changing summary accordingly.
Comment 6 Roan Kattouw 2009-01-27 14:45:49 UTC
Committed a proposed fix in r46341 (core) and r46342 (extension) which adds a &redirects parameter to action=opensearch, and only resolves redirects if that parameter is added. Resolving as FIXED in the hope that this satisfies everyone.
Comment 7 Brion Vibber 2009-01-27 18:10:15 UTC
It's supposed to be a useful *suggestions* search, and in fact has no requirement to be a strict *prefix* search. Destroying the functionality by default seems like a pretty crappy idea. Reopening.
Comment 8 Brion Vibber 2009-01-27 20:42:19 UTC
Reverted changes for now in r46379. For some reason the API doesn't allow a boolean parameter to default to true; perhaps it's only checking for the presence of the parameter (as with HTML check boxes) rather than paying attention to the value?

As a result, the more detailed XML search output ends up being hideously filled with "#REDIRECT Bla bla" in the results, which is strongly counter to sensible usability.

(If you're making any further changes to this, please make sure you're actually *testing* the results; check the behavior in IE 8 beta for instance.)
Comment 9 Ben Rimmington 2009-01-27 21:42:03 UTC
Now that I've seen how action=opensearch is implemented, I think this bug report could be closed as INVALID. Maybe the differences should just be documented instead.

public function getAllowedParams() {
    return array (
        // ... //
        'format' => array (
            ApiBase :: PARAM_DFLT => 'json',
            ApiBase :: PARAM_TYPE => array (
                'json',
                'jsonfm',
                'xml',
                'xmlfm',
            ),
        ),
    );
}

public function getParamDescription() {
    return array (
        // ... //
        'format' => 'The format of the output',
    );
}

public function getDescription() {
    return array (
        'This module/extension implements the OpenSearch protocol.',
        'NOTE: Redirects are only resolved for the XML and XMLFM output formats.',
    );
}

OFF TOPIC: Only 1 of 35 results for http://en.wikipedia.org/w/api.php?action=opensearch&search=Neptune&limit=50&format=xmlfm has a "badge" image. Shall I report this as a bug?

Comment 10 Gurch 2009-01-28 00:20:03 UTC
(In reply to comment #9)
> Now that I've seen how action=opensearch is implemented, I think this bug
> report could be closed as INVALID. Maybe the differences should just be
> documented instead.

Could do, does seem a bit odd though... require clients to use either an XML parser or a JSON parser depending on what they want returned? :/
Comment 11 Ben Rimmington 2009-01-28 01:24:33 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > Now that I've seen how action=opensearch is implemented, I think this bug
> > report could be closed as INVALID. Maybe the differences should just be
> > documented instead.
> 
> Could do, does seem a bit odd though... require clients to use either an XML
> parser or a JSON parser depending on what they want returned? :/
> 

You're probably right -- I only suggested it because I regret causing this disagreement over a minor bug.

I've just tried using a list=search query, but it returned an "srsearch-title-disabled" error. Otherwise, this might be an alternative to action=opensearch, and it also has an "srredirects" parameter.

http://en.wikipedia.org/w/api.php?action=query&list=search&srsearch=Neptune&srwhat=title

http://en.wikipedia.org/w/api.php?action=query&list=search&srsearch=Neptune&srwhat=text

Comment 12 Roan Kattouw 2009-01-28 08:58:02 UTC
(In reply to comment #8)
> Reverted changes for now in r46379. For some reason the API doesn't allow a
> boolean parameter to default to true; perhaps it's only checking for the
> presence of the parameter (as with HTML check boxes) rather than paying
> attention to the value?
> 
Yeah, that's what it does. In example requests, boolean parameters aren't even set to a value (some clients set them to 1 or 'yes' or something like that, but that's their choice). Of course we could add a &noredirect parameter instead, or just keep the &redirects parameter and tell clients/plugins/whatever that adding an extra parameter to their request isn't the end of the world.

(In reply to comment #10)
> (In reply to comment #9)
> > Now that I've seen how action=opensearch is implemented, I think this bug
> > report could be closed as INVALID. Maybe the differences should just be
> > documented instead.
> 
> Could do, does seem a bit odd though... require clients to use either an XML
> parser or a JSON parser depending on what they want returned? :/
> 
That's exactly the reason why I don't like the current behavior. Choosing a different format shouldn't have the side effect of toggling redirect resolution, especially if it's not documented.

(In reply to comment #11)
> I've just tried using a list=search query, but it returned an
> "srsearch-title-disabled" error. Otherwise, this might be an alternative to
> action=opensearch, and it also has an "srredirects" parameter.
> 
> http://en.wikipedia.org/w/api.php?action=query&list=search&srsearch=Neptune&srwhat=title
> 
> http://en.wikipedia.org/w/api.php?action=query&list=search&srsearch=Neptune&srwhat=text
> 
If you're looking for a prefix search, use http://en.wikipedia.org/w/api.php?action=query&list=allpages&apprefix=Neptune (which incidentally, also has redirect resolution available). Either way, these requests won't return the right format for suggestion search plugins.
Comment 13 Ben Rimmington 2009-01-28 20:34:46 UTC
(In reply to comment #12)
> If you're looking for a prefix search, use
> http://en.wikipedia.org/w/api.php?action=query&list=allpages&apprefix=Neptune
> (which incidentally, also has redirect resolution available). Either way, these
> requests won't return the right format for suggestion search plugins.
> 
Thanks for the suggestion, but I've realized that list=allpages or list=search might be too inefficient (for my application). I want to display an image and description with each search result, so the OpenSearchXml extension is the best option.


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


Navigation
Links