Great.
There's now also common code for writing / reading UIMA serialization headers,
in
CommonSerDes (in org.apache.uima.cas.impl )
This includes the extensions to support versioning the serializations, which
start to be needed in the next release because a bug fix is slightly changing
the serialized form for **delta binary** CAS.
So, it would be good to use that rather than have another separate header
reader/writer to maintain.
-Marshall
On 7/19/2016 4:13 PM, Peter Klügl wrote:
> Ah, I didn't know that enum. I'll adapt the code and enum.
>
> Am 19.07.2016 um 20:09 schrieb Marshall Schor:
>> 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
>>>>>>
>
>
