jpivarski
commented
7 years ago Interesting that you picked up on that. :) I did a lot of inconsistency-squelching before the 1.0 version, and I hesitated over this exact issue: values and values:name in Bin instead of bins and bins:name. (One way or the other, they have to go together.) But the Bin aggregator is special: it's the one without an adverb.
If Bin were alone, I would think that values and values:name are a lot more natural than bins and bins:name, and I did start with Bin (I think most people would start learning there, too). But taking all the AdverblyBin aggregators as a class, Bin does seem to be the odd one out for not having bins and bins:name.
The fact that you felt the same way suggests that consistency with the other AdverblyBins is more important than the subjective oddness of Bin having a bins and bins:name. All told, that's one and a half votes for changing it. However, a change like that would require a new specification version, and I think the document says that backward incompatibility means it must be 2.0, rather than 1.1.
Rather than closing this, I'm going to see if I can assign a 2.0 milestone to it. A better handling of "Bag" is in the works, so it's more likely that there won't be many version in the 1.x series before 2.0. I'd also like to hear back from more users before doing much development. (I want to change things in ways that help users get things done, rather than flopping around on subjective things.)
isaacsanders
This seems to be an inconsistency. The type of the bin aggregators is "bins:type". In most places "bins" are named by "bins:name". The use of "values" as the root of keys like "", ":type", and ":name" is seen only in the
Binaggregator. This seems like an inconsistency that can be fixed rather simply, my solution being calling it "bins" in theBinaggregator as well as in the other aggregators, for this is currently the state of things in every other case.