I'm apologize if my tone was interpreted as being antagonistic.

Although I may have abused the use of "canonical", my intent was to suggest
that raw data I/O represents the fundamental basis required to support
arbitrarily encoded data access; and in that respect, tried to suggest that
null-encoding may be thought of as root canonical encoded form (where a null
encoding transform does nothing, therefore lossless, fully preserving all
the originally encoded data states in their native form); where then
subsequent encoding transforms may be applied once within the scheme
environment as required to extract more specific interpretation of the data
as required, based on assumption or knowledge of its encoded representation
through some means.

However under no circumstances should scheme I/O be presumed to be based on
any particular character encoding which may be different than the host
platforms presumption; as otherwise the scheme's I/O interface would then
need to presume the responsibility to transcode it's I/O, potentially
destroying the integrity of data encoded in other forms (as you yourself
implied). Although I don't think I have any axe to grind, I do have an
interest in either preserving the use of character I/O as a useable basis
for generalized data access, or requiring an alternative be formally
defined, if the present character data types and I/O facilities prevent
their use as such. (With respect to scheme identifiers being validly formed
from an extremely broad character set, I simply just don't think it a good
idea for the reasons I stated, but admittedly a lesser concern.)

Thanks, -paul-

> From: "Bradd W. Szonye" <xxxxxx@szonye.com>
> Date: Thu, 12 Feb 2004 19:35:16 -0800
> To: srfi-52@srfi.schemers.org
> Subject: Re: Encodings.
> Resent-From: srfi-52@srfi.schemers.org
> Resent-Date: Fri, 13 Feb 2004 04:35:26 +0100 (NFT)
>
> 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. ...
>
> Paul Schlie wrote:
>> Yes, therefore scheme need the fundamental ability to
>> read/process/write data encoded in arbitrary encoded formats ....
>
> Whoah! That's doesn't follow! "More than one canonical form" is not the
> same as "data encoded in arbitrary encoded formats," and therefore your
> "therefore" is incorrect.
>
>> Therefore the lowest level canonical (null-encoded) form which scheme
>> needs to support is pure binary I/O, storage, and manipulation;
>
> While I agree with your conclusion, this "therefore" is also invalid.
>
>> 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.
>
> Er, what? It sounds like you have some axe to grind, and you're using
> any excuse to pull out the grinder.
> --
> Bradd W. Szonye
> http://www.szonye.com/bradd
>