RE: [www-qa] Re: Conformance and Implementations

At 01:13 PM 10/23/01 -0600, Alex Rousskov wrote:
>On Tue, 23 Oct 2001, Mark Skall wrote:
>
> > We may be better at reading human language that XML or RDF, but
> > are we better at interpreting what was meant by the language?
>
>IMO, we are no worse at interpreting human language than interpreting
>[large pieces of] XML or RDF. Is there any reason to believe
>otherwise? We are not machines. XML and RDF are designed to make
>machine's tasks easier. It always puzzles (not to say annoys) me that
>more and more interfaces designed for _human_ interaction are
>switching to XML because of the "everything should be in XML!" crap.


Specifications are not designed for human interaction.  They are designed 
to communicate requirements in the most precise way possible. The fact that 
human interaction is required after the spec is promulgated only goes to 
prove that the English language has not worked as a precise way to 
communicate requirements.

> > Standards need to be read and interpreted by implementers.  Any
> > language that more precisely defines requirements is better than
> > one that doesn't.
>
>Not necessarily. Assembly language defines requirements better than C
>language. C language is better when it comes to reading and
>interpreting a program.


Assembly language is a completely inappropriate way to define 
requirements.  Assembly languages (and higher level programming languages 
as well) detail how something is done, not what must be done.  Formal 
languages were developed precisely to define requirements (what must be 
done).  Z, SMV, and PVS are examples of these.  They are used primarily for 
mission-critical systems.  However, the fact that we use formal 
requirements languages for precise definition of mission-critical systems 
shows that we don't use English, but rather a formal language to specify 
requirements, when we can't afford to make a mistake.  Why not eliminate 
mistakes for all software development?  The answer is because it costs too 
much to do it right and to use sophisticated mathematical languages to 
define requirements.  XML is a compromise.  It's not as precise as these 
languages but much easier to use and less costly to develop specs using it.



> > Also, any language that allows implementers to automatically
> > generate test assertions (like XML) is a useful specification
> > language.
>
>Only if assertion generation is the primary goal of writing the specs.
>I do not think it is.


It's certainly one of the goals.  Test assertions help enunciate the 
requirements.  Many times these assertions are written in XML. If 
assertions in XML better help us understand requirements, then the spec 
written in XML will allow us to essentially skip or greatly reduce the 
effort of developing the test assertions.

>Besides, it is often possible to automatically
>generate test assertions without using XML. If assertion generation is
>the primary goal, we should use Prolog or other logic-based systems to
>write specifications. Again, to me it seems like we are trying to make
>machines' work easier at the expense of human effort required to write
>and understand the specs.
>
> > I've always believed that standards are read by implementers and
> > standards committee members, not users.  Thus, readability is an
> > issue only as far as it can lead to precise and correct
> > implementations.
>
>So far, implementers and standards committee members have been humans.
>I see no proof that, in general, good specs in XML lead to more
>precise and correct implementations than good specs in English. If
>nothing else, an XML-based specs are likely to solicit fewer comments
>from non-gurus outside of the WG that do not speak XML freely.
>
>Also, in general, specs are read and interpreted by many humans that
>are not committee members or implementors. For example, thousands of
>network administrators have to interpret HTTP specs to troubleshoot
>their problems and assign blames.
>
>There are always simple edge-cases, of course, but QA WG should be
>concerned with the "big picture" issues only.
>
>Alex.

****************************************************************
Mark Skall
Chief, Software Diagnostics and Conformance Testing Division
Information Technology Laboratory
National Institute of Standards and Technology (NIST)
100 Bureau Drive, Stop 8970
Gaithersburg, MD 20899-8970

Voice: 301-975-3262
Fax:   301-590-9174
Email: skall@nist.gov
****************************************************************