[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
> Bradd W. Szonye wrote:
> ... Storing data in non-canonical form is not "broken." Also, there's
> more than one canonical form. ... Programs which disagree on the form
> of the I/O will need to translate between the two.
> ... That wouldn't help unless they agree to write the *same* canonical
> format. ...
Yes, therefore scheme need the fundamental ability to read/process/write
data encoded in arbitrary encoded formats, which precludes it from assuming
any single one. Therefore the lowest level canonical (null-encoded) form
which scheme needs to support is pure binary I/O, storage, and manipulation;
upon which multiple data encoding scheme's may be defined, and invoked as
required based on local environment, and/or application specific data
encoding and processing requirements (which incidentally is not restricted
to text, as data may often be represented various encoded forms; examples of
which include dozens of various audio, video, image, telemetry, modulation,
etc. data streams), none of which should require that scheme's
implementation be non-standardly or proprietarily extended for the mere
privilege of being able to access, manipulate, and subsequently store data
in whatever encoded form may be available to it, or as may be required.