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

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
                  yaya@dowling.edu
=====================================================

On Fri, 1 Oct 2010, Nick Spadaccini wrote:

>
>
>
> On 1/10/10 10:54 AM, "Herbert J. Bernstein" <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: www.csse.uwa.edu.au/~nick
> MBDP  M002
>
> CRICOS Provider Code: 00126G
>
> e: Nick.Spadaccini@uwa.edu.au
>
>
>
>
> _______________________________________________
> ddlm-group mailing list
> ddlm-group@iucr.org
> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

Reply to: [list | sender only]