We already have an enum in the core for various serial formats. The class is
public enum SerialFormat {
UNKNOWN,
XCAS, // with reachability filtering
XMI, // with reachability filtering
BINARY, // no filtering
COMPRESSED, // no filtering (form 4)
COMPRESSED_FILTERED, // with reachability and type and feature filtering
(form 6)
COMPRESSED_PROJECTION, // with subset of views
}
(I don't think COMPRESSED_PROJECTION is in use...)
This has been around for maybe 3 years. I would be in favor of considering
using and/or extending this as needed, rather than having two formats (that is,
the proposed SerializationFormat class).
-Marshall
On 7/19/2016 2:49 AM, Peter Klügl wrote:
> Hi,
>
>
> yes, the class should be officially available to external code. I
> already included it in the CAS Editor and in Ruta. I also plan to use it
> in our inhouse code. I'll change the enforcer rule.
>
>
> I can write the docs but any help is welcome since I do not know how
> much spare time I have for the rest of the week for this. I'll take a
> look where the documentation should be added. Haven't looked to it for
> some time ;-)
>
>
> I just chose the name of the class Richard contributed since I thought
> it is really suitable. Then, I also noticed the uimaFIT class. This is a
> not really good situation, but I would not change the name because of it.
>
>
> I would not split the API form the implementation. I do not see any
> advantages right now. The class is just a simple utils class with only
> static methods like CasCreationUtils (which is also not separated).
>
>
> Best,
>
> Peter
>
> Am 18.07.2016 um 22:26 schrieb Marshall Schor:
>> This is OK with me. I can even volunteer to write the docs (but am happy to
>> others do it :-) ).
>>
>> I'll wait to hear about the split (if any) between the public API and the
>> impl.
>>
>> And, we'll need to change the next version # to 2.9.0, from 2.8.2, due to
>> this
>> being that kind of a change.
>>
>> Is everyone OK with all of this?
>>
>> -Marshall
>>
>> On 7/18/2016 2:39 PM, Richard Eckart de Castilho wrote:
>>> I believe the intention is that this class becomes part of the public API.
>>>
>>> Also, my understanding is that it would do a superset of what the
>>> uimaFIT class by the same name does. We could then probably deprecate
>>> the respective uimaFIT class and suggest using the core class instead.
>>>
>>> Best,
>>>
>>> -- Richard
>>>
>>>> On 18.07.2016, at 20:30, Marshall Schor <[email protected]> wrote:
>>>>
>>>> This is a new class added to uimaj-core project, in org.apache.uima.util
>>>> package. This is fine if this is to be part of the official public APIs
>>>> supported by UIMA going forward; but if that is the case, it should
>>>> probably be
>>>> documented in the UIMA docs, and we'd have to change the version number
>>>> (due to
>>>> enforcer rules).
>>>>
>>>> If this is more of an internal use utilities, then it should be in one of
>>>> the
>>>> internal use packages, such as
>>>>
>>>> org.apache.uima.internal.util
>>>>
>>>> This class is similarly named to a UIMAFit class; are these related?
>>>>
>>>> If some of the APIs are to be permanent and public and part of the official
>>>> public APIs, but some are internal implementation details, please consider
>>>> using
>>>> an interface and an ".impl" (or equivalent) approach; packages which
>>>> support
>>>> these are:
>>>>
>>>> org.apache.uima.util and
>>>>
>>>> org.apache.uima.util.impl
>>>>
>>>> --------------
>>>>
>>>> If this is only an internal kind of change, not intending to affect the
>>>> official
>>>> UIMA APIs, then moving to the internal.util package will fix the "enforcer"
>>>> error the build is currently getting.
>>>>
>>>> -Marshall
>>>>
>
