Version 1.5 of ais/ai-00153.txt

Unformatted version of ais/ai-00153.txt version 1.5
Other versions for file ais/ai-00153.txt

!standard F.3.1 (04-38)          99-04-01 AI95-00153/01
!standard F.3.1 (01)
!standard F.3.1 (43)
!class binding interpretation 96-09-04
!status WG9 approved 99-06-12
!status ARG Approved (with changes) 8-0-2 99-03-25
!status work item 99-03-21
!status received 96-09-04
!priority Medium
!difficulty Medium
!subject Picture String Grammar or Composition Rules Need Tightening
!summary
Picture strings such as "++++>" are not well formed.
!question
The String "++++>" and like Strings with '>' unmatched by any '<' appear to be valid picture strings based on the following production sequence:
picture string ::= ... | non_currency_picture_string non_currency_picture_string ::= all_sign_number | ... all_sign_number ::= all_sign_fore [...] [>] all_sign_fore ::= sign_char {...}
sign_char {sign_char | ...}
sign_char ::= + | - | <
Is the picture string "++++>" well formed? (No.)
!recommendation
A '>' character can only appear in an all_sign_number if it contains '<' characters.
!wording
Extend F.3.1(43) to read:
If a picture String has '+' or '-' as fixed_LHS_sign, in a floating_LHS_sign, or in an all_sign_number, then it has no RHS_sign {or '>' character}.
!discussion
The problem is that the production for all_sign_number does not use the RHS_sign production, it contains the literal '>'. The picture string grammar and composition constraints were folded into as few words as possible, too few in this case. Some of the composition constraints could have been included in a context-free grammar but at the expense of making it much longer, and more difficult to read.
!appendix

!section F.3.1(04)
!subject Picture String Grammar or Composition Rules Need Tightening
!reference RM95-F.3.1(4,5,7,27)
!reference RM95-F.3.1(40-46)
!from Dan Lehman 96-06-26
!reference 96-5615.a Dan Lehman 96-6-27>>
!discussion

The String "++++>" and like Strings with '>' unmatched by any '<' are
valid picture Strings based on the following production sequence:

  picture_string              ::=  ... | non_currency_picture_string
  non_currency_picture_string ::= all_sign_number {...}
  all_sign_number             ::= all_sign_fore   [...] [>]
  all_sign_fore               ::= sign_char { ...} sign_char {sign_char | ...}
  sign_char                   ::= + | - | <

which can generate "++++>".

There are no composition constraints (F.3.1:40-46) that make such a
String invalid; yet this isn't intended to be a valid picture String,
according to Ben Brosgol, Robert Dewar, & Ken Fussichen.  What to do?
(F.3.1:43 forbids the occurrence of '>' only from an RHS_sign, not in
general.)

One solution is for F.3.1(43) to be extended to conclude:

    " ..., then it has no RHS_sign or occurrence of '>'. "

        ----------------------------------------------

[CAUTION:  UNINFORMED MUSING FOLLOWS (-; ]

While the above amendment to the composition rules seems to work, I'm
struck by the fact that of all the expansions listed for the 4 types of
picture_string in F.3.1(4-7) (p.421), ONLY ONE lacks a concluding [RHS_sign]
--viz., the 4th expansion for F.3.1(7), non_currency_picture_string.

So perhaps the better solution would be to amend the picture String
syntactic rules as follows:

  remove "[>]" from F.3.1(27) all_sign_number yielding

    ::= all_sign_for [radix [all_sign_aft]]              --removed [>]

  add "[RHS_sign]" to the 4th line of F.3.1(7) non_currency_picture_string ...

    ::= | all_sign_number {direct_insertion} [RHS_sign]  --added [RHS_sign]

Now, all_sign_number expands to just the 3 sign_char values '+', '-', '<';
and by F.3.1(44) only one of these sign_char values can exist in a particular
picture String.  By F.3.1(43), if + or - is in all_sign_number, there can be
NO RHS_sign value, so adding [RHS_sign] to F.3.1(7) in these cases will have
no effect--i.p., no ill effect--; and removing the All_S_N's potential for
'>' (newly) would invalidate Strings in which some direct_insertion followed
the '>', such as "<<>_0", "<<<<>BB", & "<<<>/".  But is it ever expected
that All_S_N generate "<...>" here?

And by (42), if '<' is in all_sign_number, then '>' must also occur in the
picture String; by the changes above, this '>' would have to come from
the RHS_sign, and so no possibility of RHS_sign generating '+' or '-'
exists in the suggested amendment to the 4th expansion in F.3.1(7).

Respectively, F.3.1(4 & 5)'s final expansions are:

  All_S_N {direct_insertion} fixed_$_char {direct_insertion} [RHS_sign]
  All_S_N {direct_insertion} fixed_#_currency {direct_insertion} [RHS_sign]

What would be lost are picture Strings where some direct_insertion et seqq.
followed the currently allowed occurrence of '>' (from current F.3.1:27),
such as "<<<>BBB", "<<<>$-", or "<<.<<>#BB+>".
Again, is it ever expected that All_S_N generate "<...>" here?

If indeed it IS the case that the changes to the syntactic rules I've mused
over can be made without ill effect, then the simplest change is to put the
[RHS_sign] production at the end of the 4 lines for F.3.1(3) picture_string,
removing it from all of F.3.1(4-7).

ps:  Next up:  The Hidden Meaning of F.3.1(2)!

---Dan Lehman
-------------- *

****************************************************************

Questions? Ask the ACAA Technical Agent