Discussion List Archives

[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
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 <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
>
>_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: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: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>www.csse.uwa.edu.au/~nick
>>  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
>> 
>><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
>
>
>_______________________________________________
>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]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.

Useful links