Corrigendum #9

[Asmus Freytag]

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./
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20140601/a134e840/attachment.html>