Although I have a few reservations about this solution, I can see the appeal and think it’s a decent compromise. My greatest reservation remains that we should really be looking to radically reshape classification at the next integer upgrade, and adding this element will make it harder to rationalise the standard down the line**.
That being said, @hayfield has preempted my questions very well. Here are some responses:
Are all the listed attributes and elements required?
Yes - a tag without a code and a vocabulary is, in my view, basically just noise.
Are there any other attributes or elements that a tag should have?
Depends a bit on whether you think there should be statistical tags . Seriously though this is a legitimate question. Is a statistical tag different from a sector? For the use cases I had in mind when I devised this, I think we could live without an aggregation-status, but do we really want to be splitting our use of a given vocabulary over two different classification elements based on whether or not our intended use is statistical?
Are tags required under both transaction and activity?
I think a precedent has been set to, by and large, allow for similar classification at the two levels, and I think it would be strange not to follow it. (Brief aside, sectors are non statistical at the transaction level, but regardless…).
Should tags be available as sub-elements of anything that a sector is not?
I think this would be needlessly confusing, and unless someone has a use-case in mind, I wouldn’t consider it.
Which Codelists (if any) should be used as restrictions for the various attributes?
I’m not even sure this needs a codelist associated with it. It should certainly be completely compatible with both the Sector and Sector Category codelists, but it should be useable with any of the other sector vocabularies on offer.
** Some of the confusion above is, in my view, the result of inheriting the CRS approach to classification wholesale (i.e. adding flags and use-case specific fields i.e. sector vs policy marker vs humanitarian classifiers), without abstracting it to one element and making it modular. I strongly believe that at 3.01, IATI should be moving towards a
<classification/> element, which adds a new attribute to specify what type of classification it is, and then allowing a shared semantics through various codelists. Obviously this is out of scope for this discussion, but I believe we should be moving towards this approach regardless of how we solve the current problem in the short term. This touches on another reason I preferred the sector attribute approach, which was to avoid adding more and more to the standard if possible.
As I said above, this isn’t to say that I’m against the newly agreed solution; I just think we can do better than it within the scope of an integer upgrade.