OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: Normative use of non-textual material in standards


 

> -----Original Message-----
> From: Alessandro Triglia [mailto:sandro@oss.com] 
> Sent: Tuesday, September 18, 2007 08:50
> To: 'emergency-msg@lists.oasis-open.org'
> Subject: Normative use of non-textual material in standards
> 
> 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.


I forgot, **and for which conformance target(s)**

Alessandro




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]