Brion Vibber schreef: Of course that gives a warning, since the '*' element is supposed to contain text. IIRC, the following should work: array( 'attrib1' => 'val1', 'attrib2' => 'val2', array( 'tag' => 'stuff', 'tag2' => 'stuff2', ) ) If it doesn't, we should correct the formatter so that it does. Introducing _attribs is also not a very good idea considering how that looks in other formats. Roan Kattouw (Catrope)

Brion Vibber schreef: Actually, they *are* different. _element doesn't contain any real information. It's there to facilitate displaying arrays with numerical indices in XML (tag names obviously can't be numerical, so we choose a tag name that makes sense in context but doesn't say anything new, such as <page> or <rev> as children of the <pages> or <revisions> element respectively). _element is never set directly, the code uses ApiResult::setIndexedTagName() which checks which formatter we're using, and does nothing if we're not using an XML formatter. For this reason, the non-XML formatters never get to see these _element elements, which is no problem because those formats do have a native way to represent arrays with numerical indices and therefore don't need the _element workaround. _attribs was different in that it actually *did* contain information, which would also have to be passed to other formatters. However, those formatters would then have to convert _attribs back to something that makes sense from a non-XML point of view, or you'd have to do some formatter-specific stuff in ApiResult::addValue() Roan Kattouw (Catrope)