Re: Corrigendum #9

On 6/1/2014 7:49 AM, Karl Williamson wrote:
> On 05/30/2014 12:49 PM, Asmus Freytag wrote:
>> One of the concerns was that people felt that they had to have "data
>> pipeline" style implementations (tools) go and filter these out - even
>> if there was no intent for the implementation to use them internally in
>> any way. Making clear that the standard does not require filtering
>> allows for cleaner implementations of such ("path through) tools.
>
> Thanks, I had not thought about that. I'm thinking wording something
> like this is more appropriate
>
> "Noncharacters may be openly interchanged, but it is inadvisable to do
> so without prior agreement, since at each stage any of them might be
> replaced by a REPLACEMENT CHARACTER or otherwise disposed of, at the
> sole discretion of that stage's implementation."
>
Karl,

I think you should address the pass-through style of implementation
explicitly.

"Noncharacters are designed to be used for special,
implementation-internal purposes, that puts them outside the text
content of the data. Some implementations, by necessity, use a
distributed architecture, and rely on yet other implementations for
services like transport, code conversion, and so on. For such
"pass-through" implementations, it would be inadvisable to rely on, or
replace any noncharacter, and certainly not to reject or filter them.
Doing so would make such an implementation a poor choice to serve as a
"pass through" in a distributed architecture that makes use of
noncharcters for internal purposes. In other words such an
implementation would make it impossible to bridge between the partners
in a prior agreement on the use of noncharacters, which would severely
undercut its utility."

You might want to check whether some statement like this isn't already
part of the FAQ. If it isn't, it would be the easiest to retrofit (and
the easiest place to lay out usage guidelines).

Alternatively, or in conjunction, you could propose that the text in the
core specification be tweaked to help set better expectations.

A./

_______________________________________________
Unicode mailing list
Unicode_at_unicode.org
http://unicode.org/mailman/listinfo/unicode
Received on Sun Jun 01 2014 - 14:35:11 CDT