A Thought About AF "Definitions"

David G. Durand

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.