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