Version 1.2 of ais/ai-00153.txt

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

!standard F.3.1 (04-38) 99-03-21 AI95-00153/01
!standard F.3.1 (01)
!standard F.3.1 (43)
!class binding interpretation 96-09-04
!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 99-03-21

Picture strings such as "++++>" are not well formed.

!question 99-03-21

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 99-03-21

A '>' character can only appear in an all_sign_number if it

contains '<' characters.

!wording 99-03-21

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 99-03-21

The problem is that the production for all_sign_number does not use the RHS_sign production, it contains the literal '>'. This is what comes of trying to fold the picture string grammar and composition constraints into as few words as possible. Some of the composition constraints are could have been included in a context free grammar but at the expense of making it much longer, and more difficult to read. However, in the case of all_sign_number and F.3.1(43) we compressed a little too hard. If this paragraph is written as two rules, it is much easier to read--and is even correct:

If a picture String has '+' or '-' as fixed_LHS_sign or in a floating_LHS_sign then it has no RHS_sign. If an all_sign_number contains '+' or '-' characters then it does not end in a '>' character.

In fact this might be a better way to correct the wording.

!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