> Again, thanks to Gavin for putting the work into writing up this proposal.
> Does anyone else have comments?
..
> Section 3.2.2
>
> I'm of two minds about supporting other non-ASCII character sets. On the
> one hand, lots of people are doing this already, and you can't very well
> expect them to stop. On the other hand, formalizing this will impede the
> goal of getting to internationalization of the WWW, where any client can
> talk to any server. You would get into the situation where clients and
> servers spoke different character sets, just like now (although you'd know
> it up front, rather than finding out when garbage showed up on your
> screen).
Unless non-Latin-based languages are treated as equal to Latin-based
languages, WWW should be renamed. I think the Accept-charset would
address this well: also, it suggests an architecture/protocol, and so is
inherently enabling rather than fettering.
> I suppose that if the number of supported character sets was limited
> (unlikely), clients could support them all, translating through Unicode.
> This doesn't seem like it's a probably outcome.
I think Gavin's solution comes down to that every WWW server should be
able to negotiate and supply:
* some ISO 646 based lowest-common-denominator encoding, e.g. ISO 8859-1;
* some ISO 10646 encoding for rest-of-world documents; and
* the local national character set (in English-speaking countries, this is
not needed).
The first allows good support of English readers, and majority-white
countries and their ex-colonies well. (I mention "white" not to impute
racism or at least parochialism, but to emphasise that for WWW to be able
reach a browsership in non-Western countries other than the technical and
educated classes, the small Latin-based character sets are of no use.) The
second allows support of international access of documents. The third
allows national support of local languages.
> This feature is probably necessary to support existing practice, but I
> worry it will lead to "Balkanization" of the WWW, namely clients and
> servers that don't speak to each other.
Local/regional character sets and encodings won't go away in the forseeable
future. WWW should have a "lingua franca" character set, and that
character set shouldn't be a national or regional character set: ISO
10646/Unicode is the only choice.
Such a three character set approach (LCD, internationals,
national/regional) is also fairly efficient: it means that clients and
servers can negotiate the character set for the least amount of character
mapping.
Gavin goes further and specifies particular encodings of ISO 10646 that
every server should support: I think that naturally follows.
> Of course, even with Unicode, if
> your server is serving up Thai, and I don't have any Thai fonts, I'm out of
> luck. It would be nice, though, if that didn't happen just because you and
> I use different character sets.
Perhaps a smart server could serve the fonts too: it could have
"Accept-charset" for the character sets and encodings it will handle, and
"Display-charset" for the character sets it can display. The smart server
would figure out what is needed. Alternatively, it could be done on an
exception basis: if a client can't display a character, it sends a
request somewhere to a font-server (back to the WWW server?): this may be
slow, but this is handling exceptions not normal operation.
As a side comment, I'd mention that the Extended Reference Concrete Syntax
(ERCS) proposals I am involved in developing have as an aim to allow SGML
tagging using native-language tag names (GIs), if the name characters also
appear in Unicode. This is in part to allow structure-based searching of
documents by non-English speakers using meaningful (to them) tag names. At
the moment, it is a reasonable assumption that SGML markup will only use
ISO 646 characters: the ERCS would hopefully change that, as far as SGML
documents go. If some version of HTML allows arbitrary tag names, I hope
that there are no ISO 646 dependencies.
-ricko
Rick Jelliffe email: ricko@allette.com.au
Allette Systems phone: +61 2 262 4777
Sydney, Australia fax: +61 2 262 4774