emergency-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Normative use of non-textual material in standards
- From: "Alessandro Triglia" <sandro@oss.com>
- To: <emergency-msg@lists.oasis-open.org>
- Date: Tue, 18 Sep 2007 08:49:45 -0600
Hi
I have reflected a little bit about
the implications of the use of data dictionaries and other formalisms (such as
XSD schemas) or semi-formalisms (such as tables) within a standard with respect
to conformance. Here are my tentative conclusions.
***
Conformance language (use of MUST / SHALL
/ SHOULD etc.) and conformance assessment assume that the primary language of a
standard will be some natural language--English, French, and so
on. This is sometimes referred to as "narrative" (or just "text") as
opposed to tables, figures, schemas, etc., and the portion of it that specifies
requirements (by the use of SHALL / SHOULD / MAY) is called "normative
text". In ISO standards, for example, the mark of a mandatory requirement
is the presence of the word SHALL in a sentence. If a document consists
entirely of descriptive text, tables, figures, and equations, without any
SHALL, that document can't be a standard because it doesn't
specify any requirements, and therefore there is nothing that an implementation
can claim conformance to. Such documents are typically called "technical
reports", "best practices", or other such, depending on the organization
that publishes them. They "describe" something rather than "specify"
something.
The above implies that a standard cannot
consist only of a schema, with no normative text surrounding it. Likewise,
a standard cannot consist exclusively of a data dictionary with no normative
text surrounding it. (The presence of a few SHALLs inside the data
dictionary is not sufficient to that effect.)
However, it is clearly useful to be able
to specify a subset of the requirements by using a formal language (e.g., ASN.1,
XML Schema, SDL) or some ad-hoc formalism or semi-formalism (e.g., a table
or a data dictionary). There is no doubt that, in many cases, the use
of formal languages or tables and other editorial artifacts can make a
standard much easier to read and can help prevent mistakes.
***
The key is that each instance of use of a
formalism has to be wrapped in normative text in some way. For
example:
- a fragment of XML Schema has to
be preceded by a sentence in English containing a SHALL (e.g., "the element
<abcd> SHALL have the type <xyz> specified as follows:", followed by
a type definition in XSD);
- a normative table has to be
preceded by one or more paragraphs of normative text saying that something
SHALL be (or SHALL be done) according to that table, and specifying precisely
what the table means and how it is to be used;
- a portion of a data dictionary
(comprising one or more entries) has to be preceded by one or more paragraphs of
normative text saying that something SHALL be (or SHALL be done) according to
those data dictionary (entries), and specifying precisely what the dictionary
entries mean and how they are to be used.
The normative text that "wraps" the
formalism does two things: it specifies the meaning of the formalism
(which is not needed if the formalism is well-known), and ***delegates its
normative status to the embedded formal artifact***.
This will create a complete path from the
Conformance section of the standard down into the formal or semiformal
specification, granting the appropriate normative status to everything that is
intended to be a requirement, in whatever language or notation it is expressed
(English, XML Schema, ASN.1, table, data dictionary entry,
etc.).
So it is very important that the formalism
be specified extremely well. It is very important to avoid both
ambiguity and redundance, which can easily occur when using a semi-formal
specification. In a semiformal specification, it must be very clear which
portions are normative and which are informative, and among the normative
portions, which ones are to be intepreted as SHALLs, which ones are to be
interpreted as SHOULDs, and which ones are to be interpreted as
MAYs.
If all these things are not done properly,
it will be impossible to tell what it means for an implementation to conform to
the standard, or it will be impossible to test conformance.
Alessandro
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]