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
