Definition of Values of Property Vertical_Orientation

[Asmus Freytag]

On 8/23/2022 10:12 AM, Sławomir Osipiuk wrote:
> On Tuesday, 23 August 2022, 08:51:26 (-04:00), Asmus Freytag via 
> Unicode wrote:
>
>     For compatibility with older parsers, all @missing directives are
>     wrapped in comments.
>
>
> If @missing directives are meaningful but ignored by older parsers, 
> doesn't that result in incorrect values? Is that preferable to the 
> parser simply failing on a new syntax?

In principle, yes, and we've backed out of some suggested solutions at 
one point because there was the danger that a parser might not read a field.

However, this train has left the station with Unicode 15.0; we're 
committed to moving to the new scheme for non-binary properties and will 
finish implementing it. That VO hasn't been moved over was a resource 
issue, not a policy one.

@missing directives simply provide machine readable information where 
originally we had human-readable comments. Old parsers were supposed to 
implement the default values via the human readable description of the 
properties.

>
> Would it only give incorrect values to unassigned code points?

90% of properties have a single "all other code points" value, which is 
the same for code points not listed as well as not assigned. And in most 
cases, there's a value like "No" or "Other" that's the obvious value to 
choose. Those are relatively straightforward to build into a parser (or 
an API returning property data). But it's better to be explicit as we 
now are with the @missing directives.

>
>     For some properties, such as derived bidi class, the  full scheme
>     will be present in 15.0, but vertical orientation missed the
>     cutoff, so that will be taken care of in the next version(s).
>
>     Where multiple @missing lines are used, you will no longer see
>     explicit listing of default values for reserved code points.
>
>
> Then, from a parsing perspective, Vertical_Orientation is not 
> currently complex (it has one default and all other values are 
> explicit) but it will be complex (multiple defaults) in the next version.

No, it does have complex "defaults" in the second sense of default 
(value for unassigned code point) but not for the first sense of default 
("omitted value in the listing").

Past time we got this all moved to a single scheme.

A./

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20220823/8ec9aa29/attachment.htm>