[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ddlm-group] Characterset of non-delimited strings insidecompound data items

• To: Group finalising DDLm and associated dictionaries <[email protected]>
• Subject: Re: [ddlm-group] Characterset of non-delimited strings insidecompound data items
• From: "Herbert J. Bernstein" <[email protected]>
• Date: Mon, 8 Nov 2010 21:23:01 -0500 (EST)
• In-Reply-To: <[email protected]>
• References: <[email protected]>

While I have no particular objection to excluding the close brackets from
non-delimited strings, personally I think making easy use of flex a
criterion for the design of CIF2 is not a good idea. -- Herbert
=====================================================
  Herbert J. Bernstein, Professor of Computer Science
    Dowling College, Kramer Science Center, KSC 121
         Idle Hour Blvd, Oakdale, NY, 11769

                  +1-631-244-3035
                  [email protected]
=====================================================

On Tue, 9 Nov 2010, James Hester wrote:

> Dear DDLm group,
>
> John Bollinger has alerted me to a glitch in the current DDLm
> specification, to wit: (i) close bracket characters are allowed as
> non-final characters in a non-delimited string, and (ii) there is no
> requirement for whitespace between a datavalue and the close bracket
> symbol that denotes the end of a table or list value.
>
> This means that, in order to decide whether a close bracket character
> terminates a list or is just another character in the non-delimited
> string, the parser must look ahead, potentially many levels of
> nesting.  For example:
>
> _t            [outer [inner1 inner2]]
>
>
> The parser does not know that the first close bracket closes the inner
> list until it has read past the second close bracket.   Or even more
> confusingly:
>
> _t            [ depth_1 [ depth_2 [ depth_3 x=a1[a2[a3[a4[i]]]];]]]
>
>
> While this behaviour is not intractable, it is also not possible to
> use simple lexing tools (e.g. flex) to handle such syntax.  I would
> therefore like to propose the following change to the current draft
> specification:
>
> "The characters ']' and '}' may not appear anywhere in a non-delimited
> datavalue"
>
> James.
> -- 
> T +61 (02) 9717 9907
> F +61 (02) 9717 3145
> M +61 (04) 0249 4148
> _______________________________________________
> ddlm-group mailing list
> [email protected]
> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>
_______________________________________________
ddlm-group mailing list
[email protected]
http://scripts.iucr.org/mailman/listinfo/ddlm-group

Reply to: [list | sender only]

• Follow-Ups:
  • Re: [ddlm-group] Characterset of non-delimited strings insidecompound data items (James Hester)

• References:
  • [ddlm-group] Characterset of non-delimited strings inside compounddata items (James Hester)

• Prev by Date: [ddlm-group] Characterset of non-delimited strings inside compounddata items
• Next by Date: Re: [ddlm-group] Characterset of non-delimited strings insidecompound data items
• Prev by thread: [ddlm-group] Characterset of non-delimited strings inside compounddata items
• Next by thread: Re: [ddlm-group] Characterset of non-delimited strings insidecompound data items
• Index(es):
  • Date
  • Thread