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!