Re: draft minutes from the sming interim:

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> David T Perkins writes:

David> We really need compiler directives in a standard format.

I am still not convinced.

David> There are several examples of RFCs that contain MIB modules
David> that the ADs know are illegal. And they are published anyway!
David> Why, because illegal stuff was put it, it wasn't checked,
David> agents and managers used it, and to change it to make it legal
David> would be a bigger impact than to fix it. Directives would be
David> one way to flag such illegal usage.

We have MIBs that have some more or less broken constructs but which
can be fixed easily in the next revision. We also have MIBs which have
some more or less broken constructs which can't be fixed or where a
fix is in place but the old broken definition can't be removed. I
believe that in these cases (which I think are the minority so far) a
decent comment explaining the situation is actually more useful for
readers than a bunch of compiler directives for N different compilers.

I am also concerned that we will see compiler directives just because
some compilers are broken and people want to work around this. (I have
seen that happen in proprietary MIBs where for example people had to
reproduce named number list in exactly one line because tools were
otherwise not able to deal with them correctly.)

David> I share your concern about readability, and don't want to
David> negatively impact readability. But there really is a need for a
David> standard way to specify compiler directives, and to have a few
David> standard ones. If you do not feel that it is appropriate to
David> have directives defined as part of the language (like that is
David> with the definition with ANSI-C), then we can create a separate
David> document that is for compiler writers that defines the
David> directives. Also we can say that RFCs cannot contain modules
David> with compiler directives.  Then later on after some experience,
David> we can decide if it makes sense to keep the documents separate
David> or to combine them.

My current reading on this:

(1) Comiler directives are some form of annotations.
(2) Annotations in general are best kept in separate files.

This does not prevent someone from trying to standardize annotations.

<soap>
The NMRG SMIng proposal provided a syntactical structure which did
allow to generate such annotation documents on the same syntactic
basis as the core SMIng documents. This worked by using the extension
mechanism to introduce new constructs. The majority of people at the
interim meeting however have argued strongly against this, even though
it is listed in RFC 3216 under section 4.1.6 as an accepted objective.
The rationale is that extensions have the potential to lead to
multiple extended but incompatible versions of the SMI.

What is real fun is the fact the folks on the xmlconf list just said
that in particular <xsd:appinfo> was found very useful in XML schemas,
which is of course just a mechanism to put arbitrary other XML stuff
into a schema which is not covered by the schema language...
</soap>

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>