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

[noreply at nceas.ucsb.edu]

Issue #5722 has been updated by Marten Lohstroh.

Assignee changed from Christopher Brooks to Marten Lohstroh
% Done changed from 0 to 100

Arbitrary string are allowed as record labels as of rev. 66121; the expression language is adapted to make this possible. The change is backward compatible because strings that qualify as valid Java identifiers are still allowed to be used without quoting them e.g., {a=1, b=2} is still accepted, but now {"a"=1, "b "=2} is accepted too. The only thing which should be mentioned that does not extend to the use of arbitrary strings as record labels, is the dot notation to retrieve fields e.g., {a=1,b=2}.a works, but {"a"=1, "b "=2}."b " does not work. This is not a problem because the dot notation is only a shorthand for the get() method, so {"a"=1, "b "=2}.get("b ") works fine. Quotes within quotes must be escaped e.g., {a=1, "b "=2, "_c\"!"=3}.get("_c\"!") yields the value 3.

One additional problem that has been solved is the following: because arbitrary strings include the use of periods, and periods are not allowed in port names (because it makes their identifier ambiguous), therefore RecordAssembler and RecordDisassembler now use the display name of ports (which has no formatting restrictions) to construct their types. Note that the display name is used instead of name only if it is actually defined.

----------------------------------------
Bug #5722: Check for problems with sanitized RecordToken labels
https://projects.ecoinformatics.org/ecoinfo/issues/5722#change-20387

* Author: Derik Barseghian
* Status: New
* Priority: Normal
* Assignee: Marten Lohstroh
* Category: general
* Target version: 2.5.0
* Bugzilla-Id: 5722
----------------------------------------
Filing a bug so this doesn't get forgotten - I said I'd try to look into this ptII change, r64639:
-------
Sanitize RecordToken or OrderedRecordToken labels, which means that characters like spaces will be converted to underscores.  This is necessary so that the string representations of RecordTokens can be reparsed by the expression language.  The alternative of modifying the expression language to allow strings as labels causes conflicts in the parser.
-------

I worry this change is going to cause problems...anything that expects (e.g. checks equivalence) the data in a label to come out of a RecordToken as it went in will seemingly have a problem. It also sounds like a lossy translation.


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://projects.ecoinformatics.org/ecoinfo/my/account

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20130424/a949512a/attachment.html>