uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Eckart de Castilho <...@apache.org>
Subject Re: Design choices for changing type systems with loaded JCas classes [was Re: UIMAv3 & WebAnno}
Date Sun, 07 Jan 2018 19:22:25 GMT
On 07.01.2018, at 06:06, Marshall Schor <msa@schor.com> wrote:
> 
> This only works when the different type definitions for type T keep the slots in
> the same order, with no omissions.
> (The JCas initialization for a new type system checks this.)  For example, valid
> definions for type T would be
>   T with features (none)
>   T with features f1
>   T with features f1, f2
>   T with features f1, f2, f3
>   T with features f1, f2, f3, f4
>   T with features f1, f2, f3, f4, f5 ...
> 
> You could not have T with features f2, f3  (skipping f1).  And the feature
> definitions would need to be in this exact order (it would not work for T with
> features f2, f1).
> 
> Does this cover the case(s) in WebAnno?

It might. But it still looks like a rather fragile construction that
might better be avoided. What does the order of the features depend on?
Alphanumeric sorting? Order in the JCas class / TSD XML?

Let's say I do this: 

- define a TSD in XML with features in the order f1, f2, f3
- generate JCas classes from that XML
- refactor the XML for some reason, reordering the features into f3, f2, f1
- *not* regenerate the JCas classes (since actually the information content
  didn't change and the order of fields in Java classes normally don't matter
  anyway)

Is such a thing supported in v3? Was it supported in v2?

Cheers,

-- Richard



Mime
View raw message