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

Re: [ddlm-group] A modest addition to the DDLm spec. .

If that gets me a concatenation operator, I'll go for it.  Thanks -- Herbert


At 4:18 PM +0000 10/1/10, SIMON WESTRIP wrote:
>Thanks for this Herbert
>
>I would certainly be more inclined to support a mechanism that
>didnt appear to introduce further restrictions or lead to confusion,
>i.e.
>loop_ _item 'A' + 'B' would still be three values (no confusion or 
>questions of possible erroneous use of the +)
>while loop_ 'A' _ 'B' could only be one value.
>
>Certainly the chances of finding an isolated _ in a valid CIF1 are 
>minimal (if not zero)?
>
>Anyway, I'm still thinking about all this, but perhaps use of the 
>underscore might be more palatable?
>
>Cheers
>
>Simon
>
>
>
>From: Herbert J. Bernstein <yaya@bernstein-plus-sons.com>
>To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
>Sent: Friday, 1 October, 2010 17:05:11
>Subject: Re: [ddlm-group] A modest addition to the DDLm spec. .
>
>Dear Simon,
>
>   I am proposing that an unquoted + between two quoted strings would
>cause those two quoted string to be concatenated.
>
>   I am not proposing any change for + in any other context.  In particular
>I am not proposing + as a concatenation operator for whitespace delimited
>strings.
>
>   I have no objection to using "_" instead "+".  The only reason for
>favoring "+" is that we already have to handle it that way in dREL,
>so there is a certain consistency to it.
>
>   Regards,
>     Herbert
>
>
>
>At 3:56 PM +0000 10/1/10, SIMON WESTRIP wrote:
>>Dear Herbert
>>
>>Just a couple of questions:
>>
>>Are you proposing that the use of an isolated (whitespace-delimited)
>>+ character is being restricted
>>rather than the use of + in whitespace-delmited strings of length >
>>1, or are you proposing that
>>the use of + is to be forbidden in whitespace-delimited strings?
>>
>>Secondly, as far as I can tell an 'isolated' underscore is a syntax
>>error. Could it be used in
>>place of the + in your mechanism, thus avoiding further restriction
>>to the use of +?
>>
>>Cheers
>>
>>Simon
>>
>>
>>
>>From: Herbert J. Bernstein 
>><<mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com>
>>To: <mailto:Nick.Spadaccini@uwa.edu.au>Nick.Spadaccini@uwa.edu.au; 
>>Group finalising DDLm and associated
>>dictionaries <<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org>
>>Sent: Friday, 1 October, 2010 12:32:01
>>Subject: Re: [ddlm-group] A modest addition to the DDLm spec. .
>>
>>Yes Nick, just as we made a variety of other characters no longer
>>valid as unquoted strings, the + would have to be quoted.  As I said,
>>this is no worse a change than the bracketed constructs themselves.
>>
>>In dicussing this, could we please stick to realistic examples.
>>There is no current
>>
>>_atom_site.charge_sign
>>
>>tag.  The charge is given by _chemical_conn_atom.charge
>>which has an integer value, not an isolated sign.
>>
>>Are the any existing CIFs that are using isolated "+" signs
>>among strings?  Those we should consider and be sure we have
>>an appropriate conversion utility brought to the attention
>>of their users just as we will have to do with all the other
>>string changes CIF2 will bring.
>>
>>My suggest helps precisely in writing such a utility, making
>>it easier to write that utility.
>>=====================================================
>>   Herbert J. Bernstein, Professor of Computer Science
>>     Dowling College, Kramer Science Center, KSC 121
>>         Idle Hour Blvd, Oakdale, NY, 11769
>>
>>                   +1-631-244-3035
>> 
>><mailto:<mailto:yaya@dowling.edu>yaya@dowling.edu><mailto:yaya@dowling.edu>yaya@dowling.edu
>>=====================================================
>>
>>On Fri, 1 Oct 2010, Nick Spadaccini wrote:
>>
>>>
>>>
>>>
>>>   On 1/10/10 10:54 AM, "Herbert J. Bernstein"
>>><<mailto:<mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com><mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com>
>>>   wrote:
>  >>
>>>>   Dear Nic,
>>>>
>>>>     If the spec is quoted string literal + quoted string litera;,
>>>>   +4 is no problem, it is just +4.
>>>
>>>   Unfortunately this means that a + can't be a legitimate unquoted string in
>>>   the presence of quoted strings, but can be if NOT in the 
>>>presence of quoted
>>>   strings. This surely has to be confusing. Example
>>>
>>>   loop_
>>>
>>>   atom_site.id
>>>   atom_site.charge_sign
>>>   atom_site.atom_type
>>>
>>>   "C123" + "C"
>>>
>>>   would return C123C plus an error for the missing data values for the last
>>>   two items.
>>>
>>>   At a lexical level
>>>
>>>   "C123" + "C" is different to "C123" + C and different to C123 + C.
>>>
>>>   Since people use quoted and unquoted strings interchangeably I fear this
>>>   will give rise to ambiguity. Of course if you do away completely with
>>>   unquoted strings (I have argued this) the problem disappears. If 
>>>all strings
>>>   have to be quoted then the symbol + will have a completely unique
>>>   interpretation.
>>>
>>>>   "breaking the underlying structure of a
>>>>   tag-value construct in the original STAR/CIF" is no more done
>>>>   by this extension than it was by the bracketed constructs.
>>>
>>>   This is a little disingenuous. The bracketed constructs were extensions to
>>   > make the representation more powerful. It actually didn't break the
>>>   underlying structure, since [string] was already allowed in the syntax. It
>>>   merely made the interpretation of the contents more in line with
>>>   expectation. The PDB had littered its data with [1,2,3] (no spaces) as
>>>   unquoted strings expressly representing lists. We just formalised it.
>>>
>>>   However
>>>
>>>   single tag - single value is the definition of the STAR/CIF 
>>>syntax. The new
>>>   formalism does break that.
>>>
>>>   But this is all moot. CIF2 is developing in a very different direction to
>>>   STAR and is no longer a subset. It is in some ways and an 
>>>extension in many
>>>   others. DDLm can be extended to incorporate some of the changes to
>>>   definition language, but there are syntax variations that cannot. The same
>>>   with dREL where quite different language extensions need to be 
>>>incorporated.
>>>
>>>   CIF2 is developing its very own syntactic definitions, its own DDL and
>>>   supporting scripting language, all of which can be based on STAR, DDLm and
>>>   dREL, yet very different.
>>>
>>>   The DDLm and dREL syntax and examples Syd and I issued for consideration
>>>   provides a good basis for this group to move forward. I am under pressure
>>>   from Syd to finalise the STAR, DDLm and dREL we implemented in to journal
>>>   papers - which I will do. I am under more pressure from my Faculty in
>>>   different directions. Time is short and my contribution to CIF2 
>>>discussions
>>>   is at best minimal, and of late non-existent. Good luck with these
>>>   developments and I hope to see applications in the near future 
>>>that exploit
>>>   its possibilities.
>>>
>>>   cheers
>>>
>>>   Nick
>>>
>>>   --------------------------------
>>>   Associate Professor N. Spadaccini, PhD
>>>   School of Computer Science & Software Engineering
>>>
>>>   The University of Western Australia    t: +61 (0)8 6488 3452
>>>   35 Stirling Highway                    f: +61 (0)8 6488 1089
>>>   CRAWLEY, Perth,  WA  6009 AUSTRALIA  w3:
>>><<http://www.csse.uwa.edu.au/%7Enick>http://www.csse.uwa.edu.au/%7Enick><http://www.csse.uwa.edu.au/%7Enick>www.csse.uwa.edu.au/~nick
>>>   MBDP  M002
>>>
>>>   CRICOS Provider Code: 00126G
>>>
>>>   e: 
>>><mailto:<mailto:Nick.Spadaccini@uwa.edu.au>Nick.Spadaccini@uwa.edu.au><mailto:Nick.Spadaccini@uwa.edu.au>Nick.Spadaccini@uwa.edu.au
>>>
>>>
>>>
>>>
>>>   _______________________________________________
>>>   ddlm-group mailing list
>>> 
>>><mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org
>>>
>>><<http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group><http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>>
>>_______________________________________________
>>ddlm-group mailing list
>><mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org
>  ><<http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group><http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>
>>
>>_______________________________________________
>>ddlm-group mailing list
>><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org
>><http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group
>
>
>--
>=====================================================
>   Herbert J. Bernstein, Professor of Computer Science
>     Dowling College, Kramer Science Center, KSC 121
>         Idle Hour Blvd, Oakdale, NY, 11769
>
>                   +1-631-244-3035
>                   <mailto:yaya@dowling.edu>yaya@dowling.edu
>=====================================================
>_______________________________________________
>ddlm-group mailing list
><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org
><http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group
>
>
>_______________________________________________
>ddlm-group mailing list
>ddlm-group@iucr.org
>http://scripts.iucr.org/mailman/listinfo/ddlm-group


-- 
=====================================================
  Herbert J. Bernstein, Professor of Computer Science
    Dowling College, Kramer Science Center, KSC 121
         Idle Hour Blvd, Oakdale, NY, 11769

                  +1-631-244-3035
                  yaya@dowling.edu
=====================================================
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

Reply to: [list | sender only]