[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:22:36 -0400
- In-Reply-To: <939146.35320.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><a06240802c8cbb6158368@[192.168.2.104]><939146.35320.qm@web87005.mail.ird.yahoo.com>
If that gets me a concatenation operator, I'll go for it. Thanks -- Herbert At 4:18 PM +0000 10/1/10, SIMON WESTRIP wrote: >Thanks for this Herbert > >I would certainly be more inclined to support a mechanism that >didnt appear to introduce further restrictions or lead to confusion, >i.e. >loop_ _item 'A' + 'B' would still be three values (no confusion or >questions of possible erroneous use of the +) >while loop_ 'A' _ 'B' could only be one value. > >Certainly the chances of finding an isolated _ in a valid CIF1 are >minimal (if not zero)? > >Anyway, I'm still thinking about all this, but perhaps use of the >underscore might be more palatable? > >Cheers > >Simon > > > >From: Herbert J. Bernstein <yaya@bernstein-plus-sons.com> >To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org> >Sent: Friday, 1 October, 2010 17:05:11 >Subject: 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 >><<mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com> >>To: <mailto:Nick.Spadaccini@uwa.edu.au>Nick.Spadaccini@uwa.edu.au; >>Group finalising DDLm and associated >>dictionaries <<mailto:ddlm-group@iucr.org>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:<mailto:yaya@dowling.edu>yaya@dowling.edu><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:<mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com><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>http://www.csse.uwa.edu.au/%7Enick><http://www.csse.uwa.edu.au/%7Enick>www.csse.uwa.edu.au/~nick >>> MBDP M002 >>> >>> CRICOS Provider Code: 00126G >>> >>> e: >>><mailto:<mailto:Nick.Spadaccini@uwa.edu.au>Nick.Spadaccini@uwa.edu.au><mailto:Nick.Spadaccini@uwa.edu.au>Nick.Spadaccini@uwa.edu.au >>> >>> >>> >>> >>> _______________________________________________ >>> ddlm-group mailing list >>> >>><mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><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><http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group >>> >>_______________________________________________ >>ddlm-group mailing list >><mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><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><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 > > >-- >===================================================== > 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 >===================================================== >_______________________________________________ >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)
- 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):