Loading ...
Sorry, an error occurred while loading the content.

Re: Suggestions for FF[5

Expand Messages
  • Robin Trew
    ... I think that this proposal, combined with Hyoungsoo s draft set of EBNF productions, form an excellent initiative which will be welcomed by anyone who sets
    Message 1 of 1 , Mar 7, 1999
    • 0 Attachment
      Hyoungsoo Yun (Mar 7 1999) wrote:

      >I'd like to propose that we include more *rigorous*
      >definition of SGF (e.g. in EBNF) into FF[5].

      I think that this proposal, combined with Hyoungsoo's draft set of
      EBNF productions, form an excellent initiative which will be
      welcomed by anyone who sets about writing a new SGF-processing tool.

      I would like to table two related suggestions:

      1. That the formal set of EBNF productions to be included in
      FF5 be numbered (to facilitate reference and discussion).

      2. That the spec. adopts an EBNF notation which uses the regular
      expression symbols *, +, and ?, to facilitate and abbreviate
      indications of whether or not particular elements are
      mandatory/optional and repeatable/non-repeatable.

      (i.e. the familiar meanings of:

      * "0 or more" (optional, repeatable)
      ? "0 or 1" (optional, not repeatable)
      + "1 or more" (mandatory, repeatable)
      (no symbol) "exactly 1" (mandatory, not repeatable) )

      Apart from the inherent power and economy of this notation
      (see for example its use in the official XML spec) it would
      facilitate development of a related DTD, since the syntax of
      SGML/XML DTD's requires this format.

      3. (viz HyoungSoo's comment in http://www.vilab.com/bgml/sgf4.html#notes
      >it seems too tedious to include all restrictions on property values
      >for the predefined properties, and it has been left out.)
      : That even if the listed EBNF productions do not reach all the way down
      to the data format for each property (personally I think it would be
      useful, if onerous, if they did), that the "lexical" entries for the
      grammar (the detailed discussions of each property) do at least include
      a formal regular expression pattern for each data format.

      Again, this will be required for a full DTD, and would be a very useful
      reference for anyone writing a parser, especially in a language that uses
      regular expressions.

      R
    Your message has been successfully submitted and would be delivered to recipients shortly.