[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Encodings.

This page is part of the web mail archives of SRFI 52 from before July 7th, 2015. The new archives for SRFI 52 contain all messages, not just those from before July 7th, 2015.

> 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.