On 22.05.2012 15:15, Nikola Smolenski wrote:

Including Items in an Article:

{{#data-template:Infobox
|data_item=q332211
|data_param=stuff
|foo=some value
|stuff.color=green
}}

I see no reason for creating a new parser function for inclusion of templates.

Basically, we need a way to pass a complex data object as a parameter to a template. If we don't have that, we have two alternative choices:

1) assign per-page variables to items, e.g. make {{{thingy}}} available in the article after a call to {{#load-data|thingy}}. Then you can use {{Infobox|data={{{thingy}}}}}, as usual. But I think this "global variables" approach is ugly and confusing, at least when stuff is loaded from inside templates.

2) alternatively, don't pass item from the article to the template at all. Instead, use parser functions for every access to an item property, and specify the item id as a parameter if necessary. That would create a lot of rundundancy and wouldn't allow "normal" template parameter syntax to be used to access data properties.

To me, this seems natural, because it behaves like a function call. Being able to pass complex objects as parameters directly would of course be better still.

Actually, if the template in question wants to pass the data object on to another template, we kind of need this...

Also, this syntax would not allow a template to draw data from more than one item

Correct. This could be simple enough to overcome, though I can't think of a *nice* way off hand. Off the top of my head, I'd do something like this:

... |data_item_2=q556677 |data_param_2=other_stuff |data_item_3=q114488 |data_param_3=more_stuff ...

or even:

|data_item=q332211 as stuff |data_item_2=q556677 as other_stuff |data_item_3=q114488 as more_stuff

which would probably be a requirement in phase3.

No, it's not. phase3 is about automatic listings, which require a different syntax anyway. Also, in a list, all items would use the same template and the same rendering options. No need for the ability to pass multiple items to a single template.

Rather, I would include a template normally and use a parser function within the template to access the data.

So, that would be option (2) from above.

So, instead of {{{data}}} there would be {{#data:}}, instead of {{{data.color}}} there would be {{#data:color}}, instead of {{{data.color(ACME_SURVEY_2010)}}} there would be {{#data:color|ref=ACME_SURVEY_2010}} and so on.

How would you specify which item {{#data:}} refers to, in case it's not the articles "default" item? How would you pass multiple items to a template?

One advantage is that commonly used syntax is always used, instead of inventing new syntax (as for the reference in this example).

For the most part, I tried to keep the normal syntax for template parameters, just introducing structured names (dots and colons). The syntax for selection-by-reference-id is indeed a bit awkward. Perhaps we can just drop it. If this is needed, one can always use the {{#data-value}} function with source=ACME_SURVEY_2010 (perhaps 'ref' is better than 'source').

Another advantage, this way would make data usable directly in article text, if that is wanted.

Yes, that's also something that is bothering me. I would propose for this case to implement option (1) from above: use {{#load-data|stuff}} to make the item available as {{{stuff}}} in the current scope (preprocessor frame).

That's kind of like saying "pass the item to me" instead of "pass the item to the template".

The parser function should be able to override itself by template parameters - I believe it is possible to do this.

That makes the hair in my neck stand up :)

Unrelated to the above,

"This will return the value of the color property, in the page's content language, as plain text."

I see that there is need to also select desired content language (for example, a lot of infoboxes display name of the topic in the content language and in the topic's language(s)). This has the potential to introduce additional problems, of course.

The parameter syntax is the simply way to access property values. For all fancy needs, like picking the language, use {{#data-value}} instead. Basically, the {{{data.foo}}} syntax is just a shorthand for the more powerful {{#data-value}} stuff.

Except that it's not wrapped in any HTML. Perhaps there should be an option to {{#data-value}} to turn that off completely, using form=plain or some such.

form Specifies in what form rendered, that is, in which HTML element the value should be wrapped.

    span: wrap in <span> tags, use <span> tags for parts
    div: wrap in <div> tags, use <span> tags for parts
    li: wrap in <li> tags, use <span> tags for parts

I don't like this at all, since it limits the number of possibilities, introduces yet another syntax parallel to HTML.

Yet, I don't see anything much better. A half-baked idea is to leave it to the client wikis to create their data display templates that could be used to format data appropriately.

Yes, this is kind of a nasty compromise.

On the one hand, it would be extremely cumbersome to have to re-implement the table (and other) structures for representing property values with various qualifiers, not to speak of the rendering logic for these qualifiers themselves.

On the other hand, we want to allow template authors to integrate property values in different kinds of structures, like tables and lists.

Note that with the help of the show=... parameters, template authors can still implement their own rendering of the value (or rather, statement) with all it's parts, using one {{#data-value}} call for each one.

(I see Jérémie's email now, and see that we came independently to some of the same conclusions :) )

{{#data-values}}:

But this is of course an even worse problem.

{{#data-link:data|the data item}}

Why not the usual interwiki syntax of [[wikidata:data|the data item]]?

because "data" is not an identifier for that item on the wikidata repo. YOu would have to use something like:

[[wikidata:/id/{{{data.id}}}|the data item]]

But constructing edit links this way is very cumbersome. The main intend for this function is to make it easy to provide an edit link in the infobox.

But perhaps a different syntax should be used for this. After all, the edit link would, with javascript enabled, not really be a link, but a button to activate the on-site editing feature.

Thanks for your comments!

-- daniel