Hi Patrick,
On Wednesday, 2010-11-10 21:38:41 -0500, Patrick Durusau wrote:
> > * 19.358 number:rfc-language-tag
> >
> > The replacing paragraph says "Producers may add support for consumers
> > that don't support the number:rfc-language-tag attribute by specifying
> > number:language, number:script and number:country attributes with
> > values that are implementation-dependent."
> >
> > That is quite contradictionary to the original and now deleted
> > intention "If a fall-back is provided for consumers that do not
> > support the number:rfc-language-tag attribute, producers should add
> > number:language, number:script and number:country attributes whose
> > values are as close as possible to the actual value of the
> > number:rfc-language-tag attribute. The values of these attributes
> > shall not contradict to the value of the number:rfc-language-tag
> > attribute."
> >
>
> Why is this contradictory? Same question for the next one.
Contradictory in the sense that replacing "as close as possible" with
"implementation-dependent" does not get the original intention across.
> Any "close as possible" setting is going to be implementation dependent.
> Yes?
Only a little ;-) Yes, the actual "close as possible" values may be
implementation-dependent, but in the context of BCP47/RFC5646 and ISO
639 and ISO 15924 and ISO 3166, the *:language, *:script and *:country
attributes shall not contradict the *:rfc-language-tag value. For
example, a *:rfc-language-tag='eu-biscayan-ES' could have accompanying
*:language='eu' and *:country='ES' attributes, but *:language='en' and
*:country='US' would not match at all and be contradictory.
> > Suggested correction:
> >
> > "Producers may add support for consumers that don't support the
> > number:rfc-language-tag attribute by specifying number:language,
> > number:script and number:country attributes with values as close as
> > possible to the actual value of the number:rfc-language-tag
> > attribute. Producers shall not use values for these attributes that
> > contradict the value of the table:rfc-language-tag attribute."
If we need the "implementation-dependent" wording somewhere I suggest
"Producers may add support for consumers that don't support the
number:rfc-language-tag attribute by specifying implementation-dependent
number:language, number:script and number:country attributes with values
as close as possible to the actual value of the number:rfc-language-tag
attribute. Producers shall not use values for these attributes that
contradict the value of the table:rfc-language-tag attribute."
> > * 19.598 table:condition
> >
> > "is-true-formula(expression): true if evaluation of the expression
> > yields a value that converts to logical type value true in the
> > semantics for the expression; false otherwise."
> > is added to both, "The defined conditions are:" and "The defined value
> > conditions are:"
> >
> > Having is-true-formula(expression) listed under both, defined
> > conditions and defined value conditions, does not make sense. There is
> > no difference. I propose to remove it from the defined value
> > conditions and list it only under defined conditions. See
> > http://tools.oasis-open.org/issues/browse/OFFICE-3493
> > which I set to "edits rejected".
>
> OK, I checked the issue, are we ok on this one?
Yes, keep it as is, I overlooked the condition context. I reset the
issue to Applied.
Eike
--
Oracle Open Office Calc core developer and i18n transpositionizer.
Signature key 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412
OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS
--
Please note that my @sun.com accounts are phasing out, use the
eike.rathke@oracle.com address instead. Thanks.