<div>hi mike,</div><div><br>
&gt; I ran a test to see how compatible our REPP implementations are. I tested the following:<br>
&gt;<br>
&gt; * $LOGONROOT/bin/repp standalone tool<br>
&gt; * PyDelphin&#39;s `delphin repp`<br>
&gt; * ace -Ev (with some `sed` and `awk` to format it like the others)<br>
<br></div><div>
i am excited you are doing this!  i have been meaning to look into degrees of REPP compliance for years, and like you i expect it will be worthwhile to iron out our shared understanding and implementation of this DELPH-IN sub-formalism.<br>
<br>
also, i am happy to confirm that leaving out the LKB from this comparison is justified, as its implementation of recovering character ranges after all rule applications are complete predates the work by bec (and myself) and is known to give invalid results in some cases.<br>
<br>
in sum, i would look to the REPP standalone tool as the closest we currently have to a reference implementation.  it uses the approach of explicitly keeping track of sub-string correspondences for each rule application, as described here:<br>
<br>
<a href="https://www.aclweb.org/anthology/P12-2074/" rel="noreferrer" target="_blank">https://www.aclweb.org/anthology/P12-2074/</a><br>
<br>
&gt; The third one is more troubling, because it appears that ACE and REPP both apply external group calls iteratively even though the ReppTop wiki is clear that they are should not be iterative. If someone can confirm that the wiki is incorrect, [...]<br>
<br>
this observation is surprising and potentially troubling to me!  the wiki page is in fact correct: unlike internal group calls, external calls should not in and of themselves be iterative; that would unnecessarily lump together two aspects of the REPP specification and potentially constrain modularity, viz. in a scenario where one would like to split out a rule group into an external module (e.g. to be able to parametrically turn it on or off) but does not want iteration over these rules.  if one in fact wants both, it is trivial to wrap an internal iterative group around the external module.<br>
<br>
i have made minor updates to the REPP code in the past few years, so will try to synchronize with bec about confirming your observation and actually making the tool compliant with the specification on the wiki.  if you act fast about the other two issues you noticed in the PyDelphin implementation of REPP, possibly you can recognition as the reference implementation then :-)?<br>
<br>
all best, oe<br>
</div><div dir="auto"><br></div>