http://bugzilla.ecoinformatics.org/show_bug.cgi?id=5722
Matt Jones <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #5 from Matt Jones <[email protected]> --- I don't understand why this is an issue. Records are standard dictionary type data structures, and any string key value containing Unicode characters should be allowed. To do otherwise is stomping on the key space in ways that are just too constraining. If the expression parser is having trouble with these keys, then it seems to me that is a bug with the expression language. If spaces are used as token delimiters in the expression language, then it must have an escape sequence to indicate that a reserved character such as a space is intended to be used as a literal, not a delimiter. All decent expression languages have this -- couldn't the pt expression language simply use the token escape sequences that are commonly used in regex expressions, such as using a backslash to escape the next character? Unescape it would look like: my key + 2 versus escaped it looks like: my\ key + 2 In the second instance, the space is treated as a literal, allowing 'my key' as a key? There are other possibilities from Bash, python, etc. that could be adopted. Other than spaces, are there any other constraints? Why can't record labels start with a digit? Can they start with punctuation? Are there any other reserved characters? -- You are receiving this mail because: You are the QA Contact for the bug.
_______________________________________________ Kepler-dev mailing list [email protected] http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
