[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] Updated draft from subgroup discussing encodings
- To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] Updated draft from subgroup discussing encodings
- From: SIMON WESTRIP <simonwestrip@btinternet.com>
- Date: Sat, 9 Oct 2010 10:21:31 +0100 (BST)
- In-Reply-To: <alpine.BSF.2.00.1010081831160.63987@epsilon.pair.com>
- References: <AANLkTi=10bAFL1EPXQyAdthQFEkcmGKhpjcbhm5UF31-@mail.gmail.com><957185.79909.qm@web87012.mail.ird.yahoo.com><alpine.BSF.2.00.1010081831160.63987@epsilon.pair.com>
I would prefer the first form only - i.e. treat the lonely underscore as a 'keyword'
and thus require separation by whitespace. But this preference has more to do with fitting
this operator element in the current 'classes' of cif elements.
On a related point, the draft spec states:
"A data name begins with an ASCII _ and may be followed by any number of characters within the 2048
character restriction."
I think this should read:
"A data name begins with an ASCII _ and is followed by one or more characters within the 2048
character restriction."
Or words to that effect - especially if the underscore is adopted as an operator.
Cheers
Simon
From: Herbert J. Bernstein <yaya@bernstein-plus-sons.com>
To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
Sent: Friday, 8 October, 2010 23:38:10
Subject: Re: [ddlm-group] Updated draft from subgroup discussing encodings
I think it is.
The current form of the proposal, as per your suggestion, is:
"string1" _ "string2" or
"string1"_"string2"
etc.
will represent the concatenation of string1 and string2
for any quoted strings, string1 and string2 using any
of the valid quote marks.
The first form does not conflict with any valid cif2
or cif1 construct unless we accept underscore by itself as
a tag. The second form does conflict with a cif1
quoted string and therefore should not be used if there
is any ambiguity as to whether the file in question
is a cif1 or a cif2 file.
=====================================================
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
=====================================================
On Fri, 8 Oct 2010, SIMON WESTRIP wrote:
> Dear all
>
> "Once we resolve the string concatenation operator issue..."
>
> Is this issue still on the table?
>
> Cheers
>
> Simon
>
> _________________________________________________________________________________________________________________________________
> From: James Hester <jamesrhester@gmail.com>
> To: ddlm-group <ddlm-group@iucr.org>
> Sent: Tuesday, 5 October, 2010 23:52:08
> Subject: [ddlm-group] Updated draft from subgroup discussing encodings
>
> Dear DDLm group,
>
> The encoding group that was split off this group and tasked with
> developing a mutually satisfactory approach to encodings in CIF2 has
> now produced an updated draft of the CIF2 'changes' document. Brian
> has posted this on the IUCr website at
> http://www.iucr.org/__data/assets/pdf_file/0016/41911/cif2_syntax_changes_jrh20101005.pdf
> The changes relative to the July draft are in section 2 describing the
> character set, and some additional text in section 1.
>
> Once we resolve the string concatenation operator issue, I think we
> are in good shape to take CIF2 to COMCIFS for approval. I would once
> again urge anybody with any outstanding issues regarding DDLm or dREL
> to bring those issues up as soon as possible.
>
> James.
> --
> T +61 (02) 9717 9907
> F +61 (02) 9717 3145
> M +61 (04) 0249 4148
> _______________________________________________
> ddlm-group mailing list
> ddlm-group@iucr.org
> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>
>
and thus require separation by whitespace. But this preference has more to do with fitting
this operator element in the current 'classes' of cif elements.
On a related point, the draft spec states:
"A data name begins with an ASCII _ and may be followed by any number of characters within the 2048
character restriction."
I think this should read:
"A data name begins with an ASCII _ and is followed by one or more characters within the 2048
character restriction."
Or words to that effect - especially if the underscore is adopted as an operator.
Cheers
Simon
From: Herbert J. Bernstein <yaya@bernstein-plus-sons.com>
To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
Sent: Friday, 8 October, 2010 23:38:10
Subject: Re: [ddlm-group] Updated draft from subgroup discussing encodings
I think it is.
The current form of the proposal, as per your suggestion, is:
"string1" _ "string2" or
"string1"_"string2"
etc.
will represent the concatenation of string1 and string2
for any quoted strings, string1 and string2 using any
of the valid quote marks.
The first form does not conflict with any valid cif2
or cif1 construct unless we accept underscore by itself as
a tag. The second form does conflict with a cif1
quoted string and therefore should not be used if there
is any ambiguity as to whether the file in question
is a cif1 or a cif2 file.
=====================================================
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
=====================================================
On Fri, 8 Oct 2010, SIMON WESTRIP wrote:
> Dear all
>
> "Once we resolve the string concatenation operator issue..."
>
> Is this issue still on the table?
>
> Cheers
>
> Simon
>
> _________________________________________________________________________________________________________________________________
> From: James Hester <jamesrhester@gmail.com>
> To: ddlm-group <ddlm-group@iucr.org>
> Sent: Tuesday, 5 October, 2010 23:52:08
> Subject: [ddlm-group] Updated draft from subgroup discussing encodings
>
> Dear DDLm group,
>
> The encoding group that was split off this group and tasked with
> developing a mutually satisfactory approach to encodings in CIF2 has
> now produced an updated draft of the CIF2 'changes' document. Brian
> has posted this on the IUCr website at
> http://www.iucr.org/__data/assets/pdf_file/0016/41911/cif2_syntax_changes_jrh20101005.pdf
> The changes relative to the July draft are in section 2 describing the
> character set, and some additional text in section 1.
>
> Once we resolve the string concatenation operator issue, I think we
> are in good shape to take CIF2 to COMCIFS for approval. I would once
> again urge anybody with any outstanding issues regarding DDLm or dREL
> to bring those issues up as soon as possible.
>
> James.
> --
> T +61 (02) 9717 9907
> F +61 (02) 9717 3145
> M +61 (04) 0249 4148
> _______________________________________________
> 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] Updated draft from subgroup discussing encodings (Herbert J. Bernstein)
- References:
- [ddlm-group] Updated draft from subgroup discussing encodings (James Hester)
- Re: [ddlm-group] Updated draft from subgroup discussing encodings (SIMON WESTRIP)
- Re: [ddlm-group] Updated draft from subgroup discussing encodings (Herbert J. Bernstein)
- Prev by Date: Re: [ddlm-group] Updated draft from subgroup discussing encodings
- Next by Date: Re: [ddlm-group] Updated draft from subgroup discussing encodings
- Prev by thread: Re: [ddlm-group] Updated draft from subgroup discussing encodings
- Next by thread: Re: [ddlm-group] Updated draft from subgroup discussing encodings
- Index(es):