From: Philippe Verdy (firstname.lastname@example.org)
Date: Tue Nov 25 2003 - 18:42:10 EST
Peter Kirk writes:
> The Unicode conformance clauses, in TUS 4.0 section 3.2, are written in
> terms of what "A process" may or may not do, sometimes in relation to
> "another process". But there doesn't seem to be a definition, either on
> this section or in the glossary, of "process". Is this to be understood
> in a general non-technical sense, or in some specific technical sense?
> What makes "a process" distinct from "another process"? Are two
> instances carrying out the same function to be considered the same
> process or distinct processes?
For me, a process is any function, module, or application that takes zero or
more input and attempts to interpret them as Unicode code points, to produce
either a rendering of the abstract text, or to perform transformation of
text according to definitions specified in Unicode (like a transformation
into collation weights, or canonical bit representations to check
equivalence), or to generate one or more output that is claimed by the
process to represent Unicode text.
Basically, each input or output interface of the process which trasfers text
data may include an optional normalization step, or normalization checkers
(but I don't like them as this breaks conformance clause C9 or C10 of
Unicode, and reduces the usability and interoperability of that process).
A system can be built by assembling together several processes. As these
processes may not include normalization steps on their interfaces, it is the
system that will provide them before linking these processes internally with
transparent pipes. The system itself becomes then a process. This can be
useful to transform a process that breaks in C9/10 into a envelope process
that fully respects canonical equivalences.
In such composite system, normalization checkers can still be used within
the internal processes, but these should only be used for debug purpose, and
should NOT impact the usability of these processes. A normalization checker
will be useful only if it produces debugging traces. Later these internal
checkers can be removed for performance, once the system has been fully
validated, but the normalizers used on the interface of the composite system
should NOT be removed.
<< ella for Spam Control >> has removed Spam messages and set aside
Newsletters for me
You can use it too - and it's FREE! http://www.ellaforspam.com
This archive was generated by hypermail 2.1.5 : Tue Nov 25 2003 - 19:45:43 EST