Hm, are there not two things going on here? Storing the original TS in the Form 6 file allows to load the serialized form into a CAS with a different TS. I.e. the TS of the target CAS is used for filtering, not the TS in the serialized form - this is lenient loading. I used this a lot!
I thought you were referring to an alternative scenario of filtering where during serialization the user specifies a TS for filtering (i.e. the TS which will then be in serialized file). Cheers, -- Richard > On 05.08.2016, at 00:06, Marshall Schor <[email protected]> wrote: > > I left it in, because I made a mistake in my original post. The way you > specify compressed form 6 is to include a type system, and it's fine if that > type system is the cas's own type system. This means no "filtering", but use > form 6. > > -Marshall > > On 8/4/2016 5:15 AM, Richard Eckart de Castilho wrote: >> I haven't used COMPRESSED_FILTERED so far (filter on save). >> I have used lenient loading of form 6 (filter on load). >> >> So for me it would be ok for the moment to throw an unsupported operation >> exception for COMPRESSED_FILTERED. >> >> -- Richard >> >>> On 04.08.2016, at 09:11, Peter Klügl <[email protected]> wrote: >>> >>> I added it because Richard mentioned that he would like to have it (as >>> far as I remember). I do not care since we do not need to include the >>> type system. >>> >>> >>> Am 03.08.2016 um 22:34 schrieb Marshall Schor: >>>> The save in format COMPRESSED_FILTERED only makes sense if you pass in an >>>> additional type system to represent the "filter". >>>> >>>> Some choices: >>>> >>>> Disable this - throw unsupported operation exception for saving with >>>> COMPRESSED_FILTERED until we get a real need/use-case for this. I would >>>> also do >>>> this for COMPRESSED_FILTERED_TS. *my choice* >>>> >>>> Otherwise, introduce another variant of save, which has an additional >>>> argument, >>>> which is the filtering TypeSystem, and require that form be used for these >>>> two >>>> forms. >>>> >>>> -Marshall
