Discussion List Archives

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

Re: [ddlm-group] Comments and folding within lists and tables

On 12/12/09 7:10 AM, "Joe Krahn" <krahn@niehs.nih.gov> wrote:

> In the last draft, the section on delimiting "tokens" uses the term
> whitespace, but the list is described as "ASCII space separated data
> values".
> Do all blank-space delimiters allow the general definition of
> whitespace, including comments, or are there cases where comments are
> disallowed?

Hasn't been discussed within compound data stypes.

> If the defined whitespace is used in all cases, this would be a valid table:
> { #my table
>    'hello':world #testing
> } #end of table

I can see that this is perfectly acceptable.
> Also, the list and table initiator/terminator characters do not require
> whitespace around them. Do the 1st and 3rd comments above require
> preceding blank space as defined in STAR? Or, do the "implicit
> delimiter" characteristics of those characters make it optional?

In the last version of the draft paper I issued we made a clear distinction
in the requirement of whitespace between the end of one token and the
beginning of the next. {# is the beginning of one an the beginning of
another, and hence does not require a whitespace. This was the way we got
around the fact that }} was ok and did not need it to be } }.
> The draft gives the TABLE example:
>       { ...
>       "description":"""Cubic space group
>             and metric cell vectors"""}
> Then it says it implies line joining. Does this mean that the string for
> "description" is unwrapped to the one-line string "Cubic space group and
> metric cell vectors"?

NO. I can't recall the exact wording but the intent was that between the
parts of a table/list whitespace had no meaning, but within a token like """
it would retain its meaning.


{ ...
   "description":"""Cubic space group
 and metric cell vectors"""}

Is equivalent to the tag "description" having the value
"Cubic space group and\n metric cell vectors"

> To allow for longer strings without inserting a line break, it may be
> better to allow optional space around the colon, so the above example
> could be written as:
>       { ...
>         "description":
>         "Cubic space group and metric cell vectors"
>       }
> The exclusion of : from non-quoted strings prevents this from being
> ambiguous, so I don't see a good reason not to allow whitespace around
> the colon, or perhaps only following it.

The definition will be made to allow for the above, as well as

{ ...
"Cubic space group and metric cell vectors"

Again the whitespace between the parts of a compound data type are meant to
be meaningless.



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.