On 07.01.2018, at 06:06, Marshall Schor <m...@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
