On 29.09.2017, at 22:57, Marshall Schor <m...@schor.com> wrote:
>
> Thanks Richard!
>
> Re: the change in format for toString() for Feature Structures, I'm wondering
> if
> I should see about making that more or less like v2. In your case(s), would
> it
> have to be identical to avoid failure?
uimaFIT and DKPro Core provide a component called CasDumpWriter which is
intended for use in tests to write the CAS contents to a "human readable"
format. To this end, it uses the toString() method. DKPro Core has various
tests which contain "reference" files created by the CasDumpWriter and as
part of unit tests, these files are compared to the actual output created
during the test.
Mind, this is not the best design - but it is quite convenient.
I just have to update the reference files for the new toString() format.
A bit tedious, but IMHO no reason to reconsider the format of toString().
However, there seems to be room for improvement in the toString() method
when dealing with nested annotations and multi-valued features. E.g.
the array contents in the following output do not seem to be properly
indented. Maybe one-element-per-line would also look better.
------
[Save]
#23 Token:3
sofa: sofa id: _InitialView
begin: 0 end: 4 parent: #22 Constituent:141
sofa: sofa id: _InitialView
begin: 0 end: 29 constituentType: "VP"
parent: #1 ROOT:100
sofa: sofa id: _InitialView
begin: 0 end: 169 constituentType: "S"
children: #26 FSArray:147
Array length: 3
Array elements: ["#27 Token:21
sofa: sofa id: _InitialView
beg...", "#2 Constituent:101
sofa: sofa id: _InitialView
...", "#22 "]
children: #125 FSArray:146
Array length: 2
Array elements: ["#23 ", "#24 Constituent:142
sofa: sofa id: _InitialView..."]
lemma: #143 Lemma:4
sofa: sofa id: _InitialView
begin: 0 end: 4 value: "save"
pos: #144 POS_VERB:5
sofa: sofa id: _InitialView
begin: 0 end: 4 PosValue: "VB"
coarseValue: "VERB"
id: "s115_0"
------
Cheers,
-- Richard
