There are several types of TEXT in this system and it would be convenient to be able to convert between them -- a TextReducerAppliance.
Here are some of the conversion steps I have in mind:
TEXT.ATOM <=> TEXT.WORD
TEXT.ATOM <=> TEXT.LINE
TEXT.ATOM <=> TEXT.BLOB :: Is there a reason for a blob? Should we just remove it?
TEXT.WORD <=> TEXT.LINE
Here's some extra spice: this should also handle TEXT.CUE conversions, and could potentially eliminate the concept of TEXT.SRT in favor of TEXT.CUE (note that this would be problematic to do if we don't also implement the ability to explicitly specify input streams for new appliances, since a common flow will likely be VIDEO => (rollup) CUE => ATOM => CUE => FILE
TEXT.CUE <=> TEXT.ATOM :: cues are special in that they may, or may not, be rollup (e.g. lines that include the previous text as well). Cue logic would also be responsible for detecting what has changed from the previous cue. I suppose it's possible we would want to generate cues as well.
TEXT.LINE <=> TEXT.SRT :: This might be worthwhile; it would allow us to drop the existing SRT appliance and opt for this more flexible one instead. It's also worth thinking about and explicitly defining if there is a need for TEXT.SRT or if that is really just a type of TEXT.CUE.
Feature description
There are several types of
TEXTin this system and it would be convenient to be able to convert between them -- aTextReducerAppliance.Here are some of the conversion steps I have in mind:
TEXT.ATOM<=>TEXT.WORDTEXT.ATOM<=>TEXT.LINETEXT.ATOM<=>TEXT.BLOB:: Is there a reason for a blob? Should we just remove it?TEXT.WORD<=>TEXT.LINEHere's some extra spice: this should also handle
TEXT.CUEconversions, and could potentially eliminate the concept ofTEXT.SRTin favor ofTEXT.CUE(note that this would be problematic to do if we don't also implement the ability to explicitly specify input streams for new appliances, since a common flow will likely beVIDEO => (rollup) CUE => ATOM => CUE => FILETEXT.CUE<=>TEXT.ATOM:: cues are special in that they may, or may not, be rollup (e.g. lines that include the previous text as well). Cue logic would also be responsible for detecting what has changed from the previous cue. I suppose it's possible we would want to generate cues as well.TEXT.LINE<=>TEXT.SRT:: This might be worthwhile; it would allow us to drop the existing SRT appliance and opt for this more flexible one instead. It's also worth thinking about and explicitly defining if there is a need forTEXT.SRTor if that is really just a type ofTEXT.CUE.