Thanks a lot Daniel for the update!
I think this is great progress. Picking on the point Denny raised:
With respect to the #data-item function:
Even after reading your explanation I share some of Denny's concern.
You are certainly right, that at present there is a clear solution.
However, is this solution defined to be stable in the light of ongoing
restructured of mediawiki? Is "current preprocessor frame" (which does
not say anything to me) something that will always be present, even if
mediawiki might in the end use a completely new parser?
If yes, then I only see the problem of explaining the scope-definition
slgihtly better.
> * The section "Coalescing values" is
very interesting, but I think it needs a
> bit more work and wider discussion. AFAIK usually such values are not coalesced,
> but rather just listed (which would be covered by the section "Multiple
values").
I agree with Daniel that aggregation or enumeration functionality is a must.
I am slightly unhappy with the term Coalescing, because it seems to me
misleading. E.g. the SPARQL and other programming language sense
covers only part of what seems to be addressed here, see e.g.
http://www.w3.org/TR/sparql11-query/#func-coalesce
http://en.wikipedia.org/wiki/Null_coalescing_operator
From what Daniel is describing, "aggregation"
(or perhaps specifically
enumeration) would be clearer to me.
I wonder whether it can be restricted to enumeration initially.
However, I do support a functionality of directly output multiple
values rather than forcing complex template programming recursion etc.
----
My own point, slightly more generic than this discussion:
Whenever you use "data item" or "item data" (both forms exist, with
"item data" seemingly being an abbreviation for "data item data" ;-)
), I start to think "what was this?" - the snak, the topic, the
property values?
"Topic" seems to be an excellent replacement for data item - with the
added benefit of tying into topic maps.
Gregor
PS:
1. Note: you define preferred values, but later you switch to
undefined "strong", which may or may not be a synonym. I suggest to
drop the notion of "strong" and continue to argue with preferred.
2. Please run a spelling checker, it is distracting to read at the
moment. but content goes over form, or course!