<html>
<head>
<style>
body {
font-family: Verdana, sans-serif;
font-size: 0.8em;
color:#484848;
}
h1, h2, h3 { font-family: "Trebuchet MS", Verdana, sans-serif; margin: 0px; }
h1 { font-size: 1.2em; }
h2, h3 { font-size: 1.1em; }
a, a:link, a:visited { color: #2A5685;}
a:hover, a:active { color: #c61a1a; }
a.wiki-anchor { display: none; }
hr {
width: 100%;
height: 1px;
background: #ccc;
border: 0;
}
.footer {
font-size: 0.8em;
font-style: italic;
}
</style>
</head>
<body>
<span class="header"></span>
Issue #5722 has been updated by Marten Lohstroh.
<ul>
<li><strong>Assignee</strong> changed from <i>Christopher Brooks</i> to <i>Marten Lohstroh</i></li>
<li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li>
</ul>
<p>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.</p>
<p>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.</p>
<hr />
<h1><a href="https://projects.ecoinformatics.org/ecoinfo/issues/5722#change-20387">Bug #5722: Check for problems with sanitized RecordToken labels</a></h1>
<ul>
<li>Author: Derik Barseghian</li>
<li>Status: New</li>
<li>Priority: Normal</li>
<li>Assignee: Marten Lohstroh</li>
<li>Category: general</li>
<li>Target version: 2.5.0</li>
<li>Bugzilla-Id: 5722</li>
</ul>
<p>Filing a bug so this doesn't get forgotten - I said I'd try to look into this ptII change, r64639:<br />-------<br />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.<br />-------</p>
<p>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.</p>
<hr />
<span class="footer"><p>You have received this notification because you have either subscribed to it, or are involved in it.<br />To change your notification preferences, please click here: <a class="external" href="https://projects.ecoinformatics.org/ecoinfo/my/account">https://projects.ecoinformatics.org/ecoinfo/my/account</a></p></span>
</body>
</html>