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

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

   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.


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 +?
>From: Herbert J. Bernstein <yaya@bernstein-plus-sons.com>
>To: Nick.Spadaccini@uwa.edu.au; Group finalising DDLm and associated 
>dictionaries <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
>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:yaya@dowling.edu>yaya@dowling.edu
>On Fri, 1 Oct 2010, Nick Spadaccini wrote:
>>  On 1/10/10 10:54 AM, "Herbert J. Bernstein" 
>>  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: 
>>  MBDP  M002
>>  CRICOS Provider Code: 00126G
>>  e: <mailto:Nick.Spadaccini@uwa.edu.au>Nick.Spadaccini@uwa.edu.au
>>  _______________________________________________
>>  ddlm-group mailing list
>>  <mailto:ddlm-group@iucr.org>ddlm-group@iucr.org
>ddlm-group mailing list
>ddlm-group mailing list

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

ddlm-group mailing list

Reply to: [list | sender only]