[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:22:36
Subject: Re: [ddlm-group] A modest addition to the DDLm spec. .
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]
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: Sat, 2 Oct 2010 04:27:59 -0700 (PDT)
- In-Reply-To: <a06240803c8cbbb20b1fd@[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]><939146.35320.qm@web87005.mail.ird.yahoo.com><a06240803c8cbbb20b1fd@[192.168.2.104]>
Dear all
Assuming that such a string concatenation mechanism is in no way 'restrictive',
I see no reason to shelve it.
I cannot see it as a burden for users - they would not be required to use it; in most cases they
would probably not use it; it is a new CIF2-only feature that does not invalidate CIF1 in a CIF2 context.
Developers should have no problem incorporating it - certainly no more than incorporating the
other new features of CIF2.
The perceived benefits are perhaps 'minimal', but nevertheless significant, e.g.
It could provide a line-folding mechanism that operates outside of the data value (and actually,
to my mind, might be a bit simpler/cleaner than the current mechanism).
It could be made use of for presentation purposes (the regex examples).
It could be used to interject a comment at a particular point in a lengthy text value.
Developers might find it a convenient mechanism to exploit for their own purposes,
e.g. legitimately store application-specific data relating to the contents of a data item
without having to 'corrupt' the contents of that item.
So on the whole I'm inclined to support its introduction in CIF2 if indeed it is
in no way restrictive and has no marked effect on any other aspect of CIF2 other
than the obvious (relatively trivial) extra parsing requirements.
Looking to the future (CIF3+), building on the unquestionable success of CIF2 :-), the precedence of such a
mechanism may lead to extension of the concept to concatenate data values, e.g.
_text_item 'This is the value of data item: ' _ $_data_item _ ' derived via DDLm...'
Who knows...
Cheers
Simon
Assuming that such a string concatenation mechanism is in no way 'restrictive',
I see no reason to shelve it.
I cannot see it as a burden for users - they would not be required to use it; in most cases they
would probably not use it; it is a new CIF2-only feature that does not invalidate CIF1 in a CIF2 context.
Developers should have no problem incorporating it - certainly no more than incorporating the
other new features of CIF2.
The perceived benefits are perhaps 'minimal', but nevertheless significant, e.g.
It could provide a line-folding mechanism that operates outside of the data value (and actually,
to my mind, might be a bit simpler/cleaner than the current mechanism).
It could be made use of for presentation purposes (the regex examples).
It could be used to interject a comment at a particular point in a lengthy text value.
Developers might find it a convenient mechanism to exploit for their own purposes,
e.g. legitimately store application-specific data relating to the contents of a data item
without having to 'corrupt' the contents of that item.
So on the whole I'm inclined to support its introduction in CIF2 if indeed it is
in no way restrictive and has no marked effect on any other aspect of CIF2 other
than the obvious (relatively trivial) extra parsing requirements.
Looking to the future (CIF3+), building on the unquestionable success of CIF2 :-), the precedence of such a
mechanism may lead to extension of the concept to concatenate data values, e.g.
_text_item 'This is the value of data item: ' _ $_data_item _ ' derived via DDLm...'
Who knows...
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:22:36
Subject: Re: [ddlm-group] A modest addition to the DDLm spec. .
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
_______________________________________________ ddlm-group mailing list ddlm-group@iucr.org http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- 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)
- 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: [ddlm-group] Updated draft from subgroup discussing encodings
- 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):