Last modified: 2011-05-15 10:08:19 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 14955 - Illogical XML in sitematrix API output
Illogical XML in sitematrix API output
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
SiteMatrix (Other open bugs)
unspecified
All All
: Low enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/w/api.php?act...
:
: 16003 (view as bug list)
Depends on:
Blocks: noncoreapi
  Show dependency treegraph
 
Reported: 2008-07-28 08:02 UTC by Max Semenik
Modified: 2011-05-15 10:08 UTC (History)
6 users (show)

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


Attachments

Description Max Semenik 2008-07-28 08:02:54 UTC
Currently, it gives numerous entries like
    <language code="aa" name="Afar">
      <site>
        <site url="http://aa.wikipedia.org" code="wiki" />
        <site url="http://aa.wiktionary.org" code="wiktionary" />
        <site url="http://aa.wikibooks.org" code="wikibooks" />
      </site>
    </language>

While it would be much more logical to rename the upper-level <site> element to <sites> to:
1) Make it more consistent with other parts of API
2) When parsing the XML using functions that search for elements by name, that would exclude from output the <site> element that does not contain any useful information.

Yeah, that would be a breaking change, so much discussion and caution is needed.
Comment 1 Bryan Tong Minh 2008-07-28 08:33:19 UTC
You're right about this, but I don't think breaking compatibility for aesthetic is a good idea. Suggest WONTFIX.
Comment 2 Max Semenik 2008-07-28 08:38:19 UTC
(In reply to comment #1)
> You're right about this, but I don't think breaking compatibility for aesthetic
> is a good idea. Suggest WONTFIX.
> 

First, see 2) in my rationale - I had some troubles with parsing with the current schema. Second, which tools actually use this action? For example, AWB does, but in the way that will not be affected by the proposed change.
Comment 3 Bryan Tong Minh 2008-07-28 08:44:11 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > You're right about this, but I don't think breaking compatibility for aesthetic
> > is a good idea. Suggest WONTFIX.
> > 
> 
> First, see 2) in my rationale - I had some troubles with parsing with the
> current schema. 
If you are using xpath it would be something like site/site
If you are using the DOM it would be something like document.getElementsByTagName('site') and then loop over the results and check getAttribute('url')
If you are using SAX it is a little more complicated, but not undoable if you are using OOP.

> Second, which tools actually use this action? For example, AWB
> does, but in the way that will not be affected by the proposed change.
> 

We don't know which tools will break and that is the whole problem.
Comment 4 Siebrand Mazeland 2008-08-11 08:51:35 UTC
Assigned to API lead developer.
Comment 5 Roan Kattouw 2008-08-11 21:31:51 UTC
(In reply to comment #4)
> Assigned to API lead developer.

Unassigning from me. This is an extension, not core, so it's up to the extension authors to fix the issue.
Comment 6 Chad H. 2008-10-16 12:46:31 UTC
*** Bug 16003 has been marked as a duplicate of this bug. ***
Comment 7 Roan Kattouw 2008-10-16 13:37:02 UTC
Marking as WONTFIX per comments #1 and #3.
Comment 8 Danny B. 2008-10-16 14:16:30 UTC
Reopening. Many things have been changed and tools had to accommodate.

It's tool what has to accommodate to changes in software, not software should accommodate to unknown tools. In this manor mediawiki would never fix any issue.

Semantics of the <sites> tag is indisputable.

Benefits like easier traversing as well.

Besides the tag itself can be removed since it's just double-bracketing in fact.

<language code="aa" name="Afar">
  <site url="http://aa.wikipedia.org" code="wiki" />
  <site url="http://aa.wiktionary.org" code="wiktionary" />
  <site url="http://aa.wikibooks.org" code="wikibooks" />
</language>

would make sense as well - what else can be in <language> than sites? <specials> also have only one-level nesting:

<specials>
...
  <special url="http://beta.wikiversity.org" code="betawikiversity" />
...
</specials>
Comment 9 Roan Kattouw 2008-10-16 14:18:58 UTC
The point is that it's a cosmetic change, no matter how you put it. I've made a point of not making breaking changes for merely cosmetic reasons in the past, and I won't do it now either. If the author of SiteMatrix does want to, that's his call.
Comment 10 Danny B. 2008-10-16 14:32:53 UTC
Than have the SiteMatrix author to decide if to close this bug or not. And it is not merely cosmetic, benefits are indisputable. Many have been said, I'll add another one again - smaller file size.
Comment 11 Roan Kattouw 2008-10-16 14:39:32 UTC
(In reply to comment #10)
> Than have the SiteMatrix author to decide if to close this bug or not.
Fair enough. I stand by my WONTFIX recommendation, though. Who is the SiteMatrix author, anyway?

> And it
> is not merely cosmetic, benefits are indisputable. Many have been said, I'll
> add another one again - smaller file size.
> 

There are some benefits, yes, but:
* it's not fixing anything that's really broken (the current output format isn't ideal, but it works)
* it's not adding any features big enough to warrant a breaking change

These are basically the criteria I judge breaking changes by when considering them (plus, of course, the criterion that the change should be backwards compatible wherever possible).
Comment 12 Danny B. 2008-10-16 15:04:55 UTC
Another, probably most important, issue:

Compare

http://www.mediawiki.org/w/api.php?action=sitematrix&format=xml
and
http://www.mediawiki.org/wiki/Special:SiteMatrix?action=raw

It should give the same output (except for <api> wrapper).
Comment 13 Bryan Tong Minh 2008-10-17 19:49:04 UTC
Suggest WONTFIX. Breaking backwards compatibility is bad.
Comment 14 Max Semenik 2009-11-06 13:53:30 UTC
So be it
Comment 15 Danny B. 2009-11-07 20:19:44 UTC
Reopening because of comment #12. This has been discussed on #wikimedia-tech in those days and there was a consensus that it should be repaired.
Comment 16 Sam Reed (reedy) 2011-05-01 17:56:29 UTC
I've fixed the RAW output in r87200

The only difference now is the outer <api></api> and the fact that in the API specials come first, and languages second, in RAW this is the other way round. I don't see this as an issue, as using a proper XML parser, it should work either way

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


Navigation
Links