Re: [Cif2-encoding] A new(?) compromise position

I think the crux of issue is as follows:

[But part of our difficulty is that we are all having separate
epiphanies, and focusing on five different "cruxes". Clarifying
the real divergence between our views would be a genuine benefit of
a Skype conference, to which I have no personal objection.]

In the real world, a need may arise to exchange CIFs constructed in
non-canonical encodings. ("Canonical" probably means UTF-8 and/or
UTF-16). Such a need would involve some transcoding strategy.

What is the actual likelihood of that need arising?

I would characterise James's position as "not very, and even less
if the software written to generate CIFs is constrained to use
canonical encodings within the standard".

I would characterise the position of the rest of us as "reasonable to
high, so that we wish to formulate the standard in a way that
recognises non-canonical encodings and helps to establish or at
least inform appropriate transcoding strategies". There appear to be
strong disagreements among us, but in fact there's a lot of common
ground, and a drafting exercise would probably move us towards a
consensus.

Do you agree that that is a fair assessment?

If so, we can analyse further: what are the implications of mandating
a canonical encoding or not if judgement (a) is wrong and if judgement
(b) is wrong? My feeling is that the world will not end - or even
change very much - in any case; but it could determine whether we
need to formulate an optimal transcoding strategy now, or can defer
it to a later date.

However, if anyone thinks this is just another diversion, I'll drop
this line of approach so as not to slow things down even more.

Regards
Brian

On Tue, Sep 28, 2010 at 09:28:25PM -0400, Herbert J. Bernstein wrote:
> John,
>
> Now I am totally confused about what you are proposing and agree with Simon
> that what is needed for you to state your proposal as the precise wording
> that you propose to insert and/or change in the current CIF2 change document
> "5 July 2010: draft of changes to the existing CIF 1.1 specification
> for public discussion"
>
> If I understand your proposal correctly, the _only_ thing you are proposing
> that differs in any way from my proposed motion is a mandate that a
> CIF2 conformant reader must be able to read a UTF8 CIF2 file, but
> that _no_ CIF application would actually be required to provide such
> code, provided there was some mechanism available to transcode from
> UTF8 to the local encoding,
> which does not seem to be a mandate on the conformant CIF2 reader at
> all, but a requirement for the provision of a portable utility to
> do that external transcoding.
>
> If that is the case, wouldn't it make more sense to just provide that
> utility that to argue about whether my motion requires somebody to write
> their own?  Having the utility in hand would avoid having multiple,
> conflicting interpretations of this input transcoding requirement.
>
> If I have read your message correctly, please just write the utility you
> are proposing.  If I have read your message incorrectly, please
> write the specification changes you propose for the draft changes
> in place of the changes in my motion.
>
> _This_ is why it was, is, and will remain a good idea to simply have
> a meeting and talk these things out.
>
>
>