This is another tack on the architectural form and Annex C problems that Steve and I raise in the main document. The reason that Annex C is not ready for standardization as it stands is that it fails to define what is needed to make it really implementable. Since the AF definitions are not, even according to Annex C itself, formal enough to be machine processed, they ought to be renamed "Conventions for Documenting Architectural Forms". As such, they may remain normative, defining a useful and standard way to document AFs in accordance with the conventions adopted by HyTime.
To really make a standard for defining AFs, we would need a formal data model for SGML documents (DSSSL makes a good start there), a specification of what information is available to AF processors (for instance non-SGML auxiliary data might be involved), a specification of exactly what parser facilities are available to an AF processor, and a specification of what changes (if any) that AF processor might be able to make in the processing of the SGML data stream.
This could be done in a language-independent way, but ought to be at a level of detail where language bindings could be developed for existing programming languages that would enable the implementation of a completely automatic AF processor.
The canonical example here would be the YACC grammar formalism, which has a very interface between parser algorithm and application code. This interface is well enough defined that YACC has been trivially adapted to many languages without doing violence to YACC or the langages used with it.
So, the concrete proposal is that we change the word "definition" in Annex C to "documentation" -- that also reflects its use in the the HyTime standard anyway -- the declarations in the standard document, for a human being, how a HyTime processor should interpret certain special SGML documents.
This approach is a satisfactory alternative to the other Annex C changes suggested in our TC comments.