[kepler-dev] [Bug 5722] Check for problems with sanitized RecordToken labels

[bugzilla-daemon at ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=5722

Matt Jones <jones at nceas.ucsb.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jones at nceas.ucsb.edu

--- Comment #5 from Matt Jones <jones at nceas.ucsb.edu> ---
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20121205/6c0a8e9f/attachment-0001.html>