Re: Collating bug with period?

[Keld Jørn Simonsen <keld at dkuug dot dk>]

On Mon, Apr 11, 2005 at 11:23:12PM +0200, Denis Barbier wrote:
> On Wed, Apr 06, 2005 at 11:25:19AM +0200, Keld Jørn Simonsen wrote:
> [...]
> > What do yoy mean by "not scaling"? Glibc has a mechanism "reorder-after"
> > that can build on an existing LC_COLLATE spec and then just reorder a
> > few characters, like the PERIOD character. This functionality is also
> > included in ISO 14651 and TR 14652.
> 
> While you are talking about TR 14652, I have questions about its
> LC_COLLATE definition.  The 'copy' keyword is defined by:
>   copy   Specify the name of an existing FDCC-set to be
>          used as the source for the definition of this
>          category. If this keyword is specified, only the
>          "reorder-after", "reorder-end", "reorder-scripts-
>          after" and "reorder-scripts-end" keywords may
>          also be specified. The FDCC-set shall be copied
>          in source form.
> 
> This is very annoying, because new collation symbols can not be defined.
> For instance, appendix B.2 (about Danish delta) of ISO 14651 cannot be
> implemented as a tailoring delta because 'collating-element' and
> 'collating-symbol' keywords must be added after 'copy'.
> It is also not clear why multiple 'copy' are not valid (om_ET locale
> uses two 'copy').
> And toogling keywords are also not allowed in conjunction with 'copy',
> so the "gensort" example from TR 14652 is not valid.
> 
> Why all these restrictions about this 'copy' keyword?  It should work
> like an 'include' statement, otherwise it is pretty useless.

Hmm, we could look at doing an extension to 14652 here.
Yes, the semantics of an include statement is well known.
Why not extend the meaning of "copy" then?

Best regards
Keld