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

Re: [ddlm-group] Draft EBNF for CIF2

Sounds good to me. -- Herbert

On Thu, Aug 28, 2014 at 8:33 PM, James Hester <jamesrhester@gmail.com> wrote:
> Shall we wrap up this discussion then along the following lines:
>
> (1) Nested save frames are removed from the CIF2 EBNF syntax specification
> (2) Nested save frames will not be used in COMCIFS-approved DDLm
> dictionaries
> (3) Documentation can point to the STAR2 specification and repeat the
> comments that John B has made regarding handling nested save frames.
>
> Unless there are clear objections to (1) and (2) over the next few (working)
> days, I think we can consider the CIF2 EBNF with nested save frames removed
> as accepted by us and commence/continue work on supporting software and
> documentation.  At a later stage I plan to post the EBNF to our github site
> together with a FAQ document.
>
> all the best,
> James.
>
>
> On Thu, Aug 28, 2014 at 7:08 AM, yayahjb <yayahjb@gmail.com> wrote:
>>
>> We will have a lot less trouble with the new dictionaries if we don't use
>> nested save frames in them.
>> We don't need nested save frames in a dictionary. We don't need any save
>> frames, nest, or otherwise
>> in a data file. Let's save nesting of save frames until we have an actual
>> use case.
>>
>> That being said, I am a great fan of liberal parsers than can make sense
>> of natural extensions of the
>> language they should formally read.
>>
>>
>>
>> On 8/27/14 10:40 AM, Bollinger, John C wrote:
>>>
>>> I'm having trouble seeing the down side of providing for save frame
>>> nesting in the CIF2 syntax specifications.  Doing so would enable *but not
>>> require* nested frames to be used in DDLm and DDLm dictionaries, but any way
>>> around they are irrelevant to DDL1 and DDL2 dictionaries (whether written in
>>> CIF1 or CIF2 syntax) and to all CIF data files currently envisioned.  To a
>>> parser that does not understand them, nested frames will look like a
>>> combination of a missing frame terminator between adjacent frames plus an
>>> extraneous frame terminator at some later point, and such a parser must be
>>> prepared to handle those errors in some way anyway (that is exactly the CIF1
>>> situation).  A parser specialized for a domain to which nested save frames
>>> are not relevant can be such a parser, since nested frames would be
>>> erroneous in its target domain anyway.
>>>
>>> On the other hand, allowing nested frames in the syntax would maximize
>>> our leverage from the Perth group's existing tools and recent work.
>>>
>>>
>>> Regards,
>>>
>>> John
>>>
>>>
>>
>>
>> _______________________________________________
>> ddlm-group mailing list
>> ddlm-group@iucr.org
>> http://mailman.iucr.org/mailman/listinfo/ddlm-group
>
>
>
>
> --
> T +61 (02) 9717 9907
> F +61 (02) 9717 3145
> M +61 (04) 0249 4148
>
> _______________________________________________
> ddlm-group mailing list
> ddlm-group@iucr.org
> http://mailman.iucr.org/mailman/listinfo/ddlm-group
>
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://mailman.iucr.org/mailman/listinfo/ddlm-group

Reply to: [list | sender only]