Re: Proposal for isolation characters in Unicode and the unicode-bidi:isolate and unicode-bidi:plaintext definitions

> I don't understand your logic. You say option 2 offers greater forward
compatibility,
> but then say you are choosing 2 because forward compatibility is NOT
important.

Not because it isn't important, but because in certain cases is LESS
important than another consideration. It's a trade-off.

In other words, I think that well-formed documents, i.e. ones where
isolates and embeddings/overrides are properly nested, should display as
well as possible on systems that do not support isolates. That is why the
proposal has been modified to include PDI. On the other hand, when it comes
to essentially broken documents, where embeddings/overrides and isolates
are not properly nested, I think it is more important to let isolates do
their job and isolate the missing and extra PDFs in the apps that do
support isolates than to make the document display as similarly as possible
on old and new apps, when apps that don't understand isolates can't
possibly display the document 100% as intended anyway.

> I think backward compatibility is more desirable, i.e., a system that
knows nothing of
> isolates should work without modification,

By definition, it can't display the document 100% as intended. We introduce
PDI is so its disability is limited to displaying isolates incorrectly (but
then limit this to when isolates and embeddings/overrides are properly
nested).

> and yet option 2 requires PDI to close an embedding/override,

Only when the isolate began before the embedding/override. If we have LRE
RLI PDI PDF, the PDI only closes the isolate, not the embedding.

> which would violate that goal. You should choose option 1 (PDI weaker
than PDF).


On Mon, Jul 9, 2012 at 8:47 AM, Glenn Adams <glenn@skynav.com> wrote:

>
> On Sun, Jul 8, 2012 at 6:52 AM, Aharon (Vladimir) Lanin <aharon@google.com
> > wrote:
>
>> 1. Make isolates weaker than embeddings/overrides, i.e. ignore a PDI when
>> a PDF is expected, and have a PDF close all isolates opened between it and
>> its marching LRE/RLE/LRO/RLO. Thus, in a, the PDI is ignored, and in b, the
>> PDF ends the scope of the RLI as well as the LRE.
>>
>> 2. Vice-versa - make isolates stronger than embeddings/overrides, i.e.
>> ignore a PDF when a PDI is expected, and have a PDI close all
>> embeddings/overrides opened between it and its marching FSI/LRI/RLI.
>> Thus, in a, the PDI ends the scope of the RLE as well as the LRI, and in b,
>> the PDF is ignored.
>>
>> Possibility 2 offers greater forward compatibility, since new and old
>> apps will interpret the PDFs as closing the same scopes when isolates are
>> not properly nested with respect to embeddings/overrides.
>>
>> Possibility 1, on the other hand, gives isolates the desirable feature of
>> isolating their surroundings from their contents - even when their contents
>> contains extra or missing PDFs.
>>
>> I have decided to go with possibility 2, since IMO
>> forward compatibility is not very important for what are, essentially,
>> broken documents.
>>
>
> I don't understand your logic. You say option 2 offers greater forward
> compatibility, but then say you are choosing 2 because forward
> compatibility is NOT important.
>
> I think backward compatibility is more desirable, i.e., a system that
> knows nothing of isolates should work without modification, and yet option
> 2 requires PDI to close an embedding/override, which would violate that
> goal. You should choose option 1 (PDI weaker than PDF).
>