Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ddlm-group] Straw poll results

On 13/10/09 11:27 PM, "James Hester" <jamesrhester@gmail.com> wrote:

> Here are the results of the straw poll.  See the end of the email for
> detailed vote counts, and note the request for a further vote on
> certain issues.
> ===========
> 1. UTF8 will be supported. Not clear on asciified version or
> binary. Therefore, please comment and vote on the following, given
> that UTF8 will be included in the new standard:
> (a) UTF8 should be supported in standard form only (i.e. 'binary'
> characters with values above 127 will appear in CIF files)
> (b) An asciified version only should be supported.  An example would
> be the syntax \uxxxx, where xxxx refers to the Unicode code point of
> the character in hexadecimal notation.  NB this is not strictly UTF8,
> but simply a Unicode representation.
> My vote: 1.a
> 2. Termination of quoted strings on first occurence of quote delimiter
> and restriction of character set for non-delimited strings: Approved,
> but not clear whether to deprecate first or move immediately to
> requirement.  Upon long consideration of Brian's email and Herbert's
> reservations, and two cups of tea, and some chocolate, I am happy to
> change my votes to 1.2 and 2.3 (and perhaps call the new CIF syntax
> 2.0 rather than 1.2), therefore I declare these proposals approved as
> a requirement in the new standard.  I'll write a separate email on
> this.
> However: Brian and James want to require whitespace between tokens
> outside compound expressions regardless of it now becoming strictly
> unnecessary in several cases.  Given that the above proposals have
> been passed, please vote again on the following options:
> (a) Whitespace is not required between tokens unless tokens could not
> otherwise be separated; writers are encouraged to pad between tokens
> (b) Whitespace must always appear between tokens outside compound expressions
> (c) Whitespace must always appear between tokens both in and outside
> compound expressions
> My vote: 2.b
> Detailed vote summary
> =====================
> Issue1:  Removing the requirement for a trailing whitespace after
> quoted strings outside of bracketed constructs.
>   Options:  1.1. Preserve the current convention as is
>             1.2. Terminate all quoted strings on the occurance of the
> trailing quoted delimiter without consideration of the next character
>             1.3  Deprecate rather than require 1.2

What does deprecate rather than require 1.2 mean? If a scientist asks, what
does the formal language specification state concerning the absolute need
for whitespace before and after a token, what is the answer?

Please don't say we deprecate (definition: earnestly disapprove of)
whitespace, that is just plain silly. In the specification a quoted string
is terminated by the first occurrence of the matching quote (1.2), or it is
terminated by a quote immediately followed by one or more whitespace (in
which case you are actually voting for 1.1).

Again (and again and again, how many times do I have to say this?)
deprecation has to do with an implementation. What are we specifying?

> 1.1: Nobody (Herbert prefers if 1.3 not an option)
> 1.2: Brian (but whitespace required between tokens), Nick, Simon
> 1.3: Herbert, James (but whitespace required between tokens)
> Difficult to determine any clear preference from John W., but he seems
> happy to go along with the changes we are discussing so long as there
> is a clear fallback position.
>   Issue2:  Restriction of the character set for non-delimited strings
> outside of bracketed constructs
>   Options  2.1.  Preserve the current convention as is
>            2.2.  Modify the current convention to deprecate use of
>                  any characters other than a strictly limited set
>                  of characters, adding a warning oon reads and
>                  defaulting to add quote marks on write
>            2.3.  Modify the current convention to forbid the use of
>                  any characters other than a strctly limited set
>                  of characters, making it an error to read a non-delimited
>                  string that does not comply even if the intention
>                  can be inferred from context

Same question, earnestly disapproving of a character set is not a
specification. What will be specified for the language? Is the , allowed or
not allowed in an unquoted string?
> 2.1: Nobody
> 2.2: Herbert, James
> 2.3: Nick, Simon, (John)
> UTF8:
> Do not use: Nobody
> Use: Simon, Brian, John
> Use, binary: Herbert, James
> Use, asciified: Nick
> A clear preference for binary or ascii can't be gleaned from Brian and
> Simon's and John's emails, so I've left them as simply 'Use'.



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: www.csse.uwa.edu.au/~nick
MBDP  M002

CRICOS Provider Code: 00126G

e: Nick.Spadaccini@uwa.edu.au

ddlm-group mailing list

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.