[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]