View source for FormalLanguageVsProse

__NOTOC__
When defining a language (such as XHTML), some requirements are defined in prose (in the case of W3C, in English) while others are defined using a formal specification. Very often, too, there is an overlap between the 2 approaches ; that's especially the case in XML Languages where a DTD or an XML Schema can be used for 2 purposes : to define the syntactic requirements set by the language and/or to allow validating documents conforming to the said language.

Issues may arise when this overlap leads to contradictions between the prose and the formal language ; such contradictions includes :
# the English prose says more than the formal language does. (Sometimes this is unavoidable -- sometimes a constraint simply cannot be stated in a particular formal language.)
# the formal language says more (ie, puts more constraints) than the English prose does ; 
# the formal language says something different from the English prose

Case 1 may lead to a situation where a document is said to be valid with regard to the formal language, while it is not conformant to the specification as described in the text, and vice versa for case 2.

Case 3 is obviously the worse, where it may be impossible to say when a document does conform or not to a specification.

See also a [http://lists.w3.org/Archives/Public/www-qa/2004Apr/0006.html thread on www-qa] on this very topic.

[http://www.faqs.org/rfcs/rfc3930.html RFC 3930] has a section on meaning in human vs computer oriented language that has some relevance for this topic.

[http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt Guidelines for the use of formal languages in IETF specifications]

= Testing Formal Languages specifications =

One of the usual characteristics of a formal language is that it is processable by a computer : this allows to imagine several ways of testing a specification formal language :
* when there is an already wide set of known conformant (or known non-conformant) instances of the language, set up a test suite to check whether a validator based on the formal language identify the documents as valid or not
* when the formal specification is encoded in different languages (e.g. XML DTD vs XML Schema), set up a test suite that generate random documents based on the said formal specifications, and see whether they cross-validate
* use the examples given in the specification as test cases to use in the validation test suite; this was done e.g. [http://people.w3.org/~dom/archives/2004/07/extracting-examples-from-a-specification/ for VoiceXML 2.1] using [http://www.w3.org/2004/07/extract-examples.xsl an XSLT]

Generation of documents based on XML Schema: see [http://www.devx.com/getHelpOn/10MinuteSolution/20354 Convert Schemas to Documents],  [http://www.isse.gmu.edu/faculty/ofut/rsrch/abstracts/xml-test01.html Generating for XML-based Web Component Interactions Using Mutation Analysis].

[http://www.w3.org/1999/02/26-modules/User/Yacker Yacker] parses BNF and creates parsers in PERL (and in Python?). It is (potentially) used with the SPARQL grammar.

Generation of instances of a formal language: [http://polygen.org/web/Polygen.english.0.html Polygen, open-source tool]

Other formal languages include:
* BNF
* SDL
* [ftp://ftp.rsa.com/pub/pkcs/ascii/layman.asc ASN.1] (see how it can be used as a [http://asn1.elibel.tm.fr/en/xml/ASN1-as-an-XML-schema-notation.htm schema language for XML])
* TTCN (?)
* Z Notation ([http://lists.w3.org/Archives/Public/www-ws-desc/2004Sep/0076.html going to be used in WSDL 2.0])
[[QA]] http://www.w3.org/QA/images/qa.png