Dear Grant,
I have read and thought a lot about your mail. Although I am not completely convinced about your reasons, I definitely believe there is merit in them. Also, I understand that you feel strongly about it, so I am willing to consider the idea of freezing the namespace once and forever.
I have a few requests for the group, though, before I commit to this decision:
1) This is the LAST TIME we decide on this issue. If we decide to freeze the namespace, we FREEZE THE NAMESPACE for good, and we will never ever ever ever ever again change our mind or even try to suggest we might possibly give a shot to evaluate whether we could eventually end up reconsidering this decision. This is the deal breaker for me.
Also, I do not believe for a moment that we will approve only backward compatible modifications to the language from now on. Such compatibility will be a happy and welcome characteristic of most modifications we will discuss and approve, but TIME WILL COME when someone proposes an incompatible modification and people in the group will go "well, this time only, it is minor, it is very important in this context, most users will never even notice it", and bang, we have approved it. THEREFORE:
2) We impose the specification of the version of the vocabulary in an attribute in the <akomaNtoso> root element. This attribute becomes a required attribute from now on, and it allows a FIXED SET OF VALUES for all backwards-compatible versions of the language. The attribute actually becomes required for all versions AFTER 3.0, i.e., it *cannot* be placed into 3.0 documents, and it is *required* for all documents of later versions (this is by itself a non-backward-compatible modification). Trying to validate a document without such attribute or with the attribute having a weird value will return a validation error right at the beginning of the validation phase.
3) I don't like the "version" attribute, which would seem to have *the Akoma Ntoso language* as the subject of the RDF statement to be generated by its specification. I nonetheless am willing to consider an attribute that implies *this specific manifestation* as the subject of the RDF triple. I suggest "uses", as follows:
