[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 <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]
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: SIMON WESTRIP <simonwestrip@btinternet.com>
- Date: Fri, 1 Oct 2010 16:18:32 +0000 (GMT)
- In-Reply-To: <a06240802c8cbb6158368@[192.168.2.104]>
- 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]>
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
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 <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
_______________________________________________ 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. . (Herbert J. Bernstein)
- 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)
- 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):