[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: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] A modest addition to the DDLm spec. .
- From: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
- Date: Fri, 1 Oct 2010 12:05:11 -0400
- In-Reply-To: <76282.89486.qm@web87005.mail.ird.yahoo.com>
- References: <C8CB9497.1415D%nick@csse.uwa.edu.au><alpine.BSF.2.00.1010010722440.70666@epsilon.pair.com><76282.89486.qm@web87005.mail.ird.yahoo.com>
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]
- Follow-Ups:
- Re: [ddlm-group] A modest addition to the DDLm spec. . (SIMON WESTRIP)
- References:
- Re: [ddlm-group] A modest addition to the DDLm spec. . (Nick Spadaccini)
- Re: [ddlm-group] A modest addition to the DDLm spec. . (Herbert J. Bernstein)
- Re: [ddlm-group] A modest addition to the DDLm spec. . (SIMON WESTRIP)
- 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. .
- Index(es):