[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] A modest addition to the DDLm spec. .
- To: Nick.Spadaccini@uwa.edu.au, Group finalising DDLm and associated dictionaries <email@example.com>
- Subject: Re: [ddlm-group] A modest addition to the DDLm spec. .
- From: "Herbert J. Bernstein" <firstname.lastname@example.org>
- Date: Fri, 1 Oct 2010 07:32:01 -0400 (EDT)
- In-Reply-To: <C8CB9497.1415Demail@example.com>
- References: <C8CB9497.1415Dfirstname.lastname@example.org>
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 email@example.com ===================================================== On Fri, 1 Oct 2010, Nick Spadaccini wrote: > > > > On 1/10/10 10:54 AM, "Herbert J. Bernstein" <firstname.lastname@example.org> > 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 > email@example.com > http://scripts.iucr.org/mailman/listinfo/ddlm-group > _______________________________________________ ddlm-group mailing list firstname.lastname@example.org http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- Re: [ddlm-group] A modest addition to the DDLm spec. . (SIMON WESTRIP)
- Re: [ddlm-group] A modest addition to the DDLm spec. . (Nick Spadaccini)
- Prev by Date: Re: [ddlm-group] A modest addition to the DDLm spec. .
- Next by Date: Re: [ddlm-group] A modest addition to the DDLm spec. .. .. .
- Prev by thread: Re: [ddlm-group] A modest addition to the DDLm spec. .
- Next by thread: Re: [ddlm-group] A modest addition to the DDLm spec. .