Re: Fwd: Re: Israeli HTML Standard

Doron Shikmoni (P85025@VM.BIU.AC.IL)
Sun, 15 Jun 1997 17:56:10 IST

Message-Id: <>
Date:         Sun, 15 Jun 1997 17:56:10 IST
From: Doron Shikmoni <P85025@VM.BIU.AC.IL>
Subject:      Re: Fwd: Re: Israeli HTML Standard
To: David Rashty +972-2-6584848 <RASHTY@WWW4.HUJI.AC.IL>,
In-Reply-To:  Message of Sun,  15 Jun 97 8:00 +0200


In response to David Rashty's posting, and subsequent followups:

Most of the facts presented in the posting are inarguably true.
It is indeed true that, at this point in time, the major part
of the Hebrew HTML pages are using the "Visual" ordering scheme
for representing bidirectional text. It is also true that support
for Implicit ordering, a-la Unicode 2.0 and RFC2070 is scarce
to say the least.

The current draft of the SI 4281 (Hebrew HTML) includes a description
of the Visual ordering support in an appendix, as "Current Practice".
This means that it is "acknowledged" - but not recognized as being

As far as I can say, the reasons for *not* definining it as standard are
as follows:

1. SI 4281 draws mainly from RFC2070 (which draws from Unicode 2.0).
   Visual ordering is not standard, according to RFC2070. Adding
   this ordering to 4281 will make it orthogonal to RFC2070; It will
   be possible for a product to be compliant with SI 4281, while not
   being RFC2070 compliant. This is an extremely undesirable effect.

   Moreover: international software makers give little or no attention
   to Israeli standards. Their primary concern is to follow international
   and Internet standards. Currently, SI 4281 is a superset of RFC2070
   (I'm sure Jony will correct me if I'm wrong on this one), but is not
   orthogonal to it.

2. It is in the primary public interest to have the market "shift" gracefully
   into Implicit ordering of bidirectional text. Having SI 4281 specify
   Implicit as standard, will help pushing non-standard implementations
   (agreeably, the vast majority of the current sites) towards migration
   to standards-based Hebrew support.

   On the other hand, adopting Visual ordering as standard is likely to
   "freeze" the Israeli Web-making market for a long time to come.

Recently, the Knesset (Israeli Parliament) has appointed a set of committees
to recommend required action items for the preparation of Israel to the
Information Technology age. One of the committees (which I had the honor
of chairing, and of which David Rashty was a member) dealt with Hebrew
and standardization. One of the primary recommendations made by this
committee was adopting of RFC2070- and Unicode 2.0-based solutions for
all "open" (mainly, Internet) information bases, in future government
contracts. This, of course, assuming that such solutions are available.

Another recommendation is to prefer, when possible, standards-based
solutions that are *not* dependent on a special, locally available
platform (i.e., a Hebrew-specific OS) - again, when such are available.

The rationale behind these recommendations is, that the market should
be "helped" to move in the right direction; using the government buying
force as a lever to achieve this goal is considered to be such help.
Combining both recommendations should hopefully lead to the "ideal"
situation, where bidirectional support is available on all platforms,
not just locally-available ones. We know for a fact, that (with or
without relation to these recommendations) browser vendors are working
on RFC2070 compliancy, with no OS dependecy.

You should note that leaving Visual ordering as "non-standard current
practice" is not making current implementations "illegal" or otherwise
unusable. Visual ordering has never been "standard" in any specification,
and, in this context, will continue to maintain the same status:
an informal "hack" that works (sort of), until fully-standard implementations

We all realize that Visual ordering of bidirectional text will stay with
us for a considerable amount of time. At the same time we need to recognize
that it is an interim solution, and by no means a final goal.

A standard is not supposed to collect all ad-hoc solutions and give them
a "Kosher" tag. It should mark a desired goal, and define the baseline
to achieve this goal. This is what I believe SI 4281 should do (and is
doing now).

On top of all this, you must recognize that the current implementations
of Visual ordering, being (after all) a "hack", are imperfect, to use
an understatement. Printing, cutting/pasting and many other functions
are sort-of possible in various levels of difficulty. This is not something
you can standardize as is. Therefore, it is clear that to have a good
support of the *Visual* ordering scheme, software (mainly browsers) will
have to be modified by their vendors. Considering point #1 above, this
is highly improbable.

Doron Shikmoni