Re: XML Blueberry (non-ASCII name characters in Japan)

[Joel Rees <rees@server.mediafusion.co.jp>]

One man's needs are another man's wants. Let me try this again, a little
more directly. Maybe someone else can pick up the pieces.

I have been assuming that non-name characters are not allowed in tag
attributes. If this assumption is wrong, then the following argument is
somewhat superfluous, and perhaps the issue of allowing the extension
characters in tags can be relegated to questions of convenience.

Westerners tend to look at the thousands of characters in Japanese, get mind
boggled, and simply assume a direct correlation with the ABCs. But those
tens-of-thousands of characters are _not_ the ABCs of Japanese (or Chinese).
They are complete syllables and complete root words. The ABCs are the two
hundred some-odd radicals that combine to make the rest.

I mentioned "mellifluous", "mellyfluous", "mellifluus", and "mellyfluus" in
an attempt to demonstrate the effect of dis-allowing the extension
characters from markup. The former is a word in current use in English, if
rare. The second and third are archaic variants. The fourth is a deliberate
misspelling.

Should we disallow any of these words from being used as tag attributes? In
a simple database, perhaps, yes. "Melodious" would probably be the preferred
attribute value, being the more common synonym. As I understand it, XML is
aimed at something significantly broader than that kind of value-limited
database.

Now, if we are going to make a rule that allows non-name characters in
attributes, or if we are going to do away with attributes, then you can say
that it is all a matter of convenience, and I would have a hard time arguing
with that. (I would find myself grumbling from time to time, but grumbling
is a feature of life and technology.)

Oh. I thought of another way around this issue. It is not presently a very
satisfying solution, but may be the ultimate solution, if it would work: Are
ideographic sequences allowed in markup (tags and attributes)? I mean
sequences of existing characters with the ideographic description characters
mixed in to show how they are supposed to combine. If so, some truly
sophisticated editor of the future would be able to build virtually any
character that can be built from the current set of radicals, and we would
be able to do with Japanese the equivalent of using "mellyfluus" (the
misspelling) in an attribute.

Joel Rees
programmer -- rees@mediafusion.co.jp
----------------------------------------------------
To be a tree supporting all information,
  giving root to the chaos
    and branches to the trivia,
      information breathing anew --
        This is the aim of Yggdrasill.
============================XML as Best Solution===
Media Fusion Co. ,Ltd.  株式会社メディアフュージョン
Amagasaki  TEL 81-6-6415-2560    FAX 81-6-6415-2556
    Tokyo　TEL 81-3-3516-2566  　FAX 81-3-3516-2567
                       http://www.mediafusion.co.jp
===================================================

----- Original Message -----
From: "Elliotte Rusty Harold" <elharo@metalab.unc.edu>
To: <xml-dev@lists.xml.org>; "www-xml-blueberry-comments"
<www-xml-blueberry-comments@w3.org>
Sent: Tuesday, July 10, 2001 6:50 AM
Subject: Re: XML Blueberry (non-ASCII name characters in Japan)


> At 5:31 PM -0400 7/9/01, John Cowan wrote:
>
>
> >I think that talk of *need* is misconceived; as I said, there is
> >no *need* to have Greek, much less Thaana, markup.  People *want*
> >to use their own language, that's all.  Why should the "newer"
> >script users be exempt from this desire?
> >
>
> Because satisfying this want is going to cost a lot of other users money
and time. That's not necessarily an insurmountable objection, but you've got
to show that the benefits outweigh the costs. You can argue about the
relative weight that should be assigned to different benefits and costs. You
can say that the richer users should absorb the costs for the benefit of the
poorer users. (Though IBM for one doesn't seem to believe that since they're
very rich, and they still want everybody else to absorb the costs of NEL for
them.)
>
> But before you can make any of these arguments, you've got to show some
benefit to what you're proposing, and so far you haven't done that! You've
yet to produce a single person from the affected Ethiopic, Burmese, Khmer,
etc. communities saying they either want or need this.
> --
>
> +-----------------------+------------------------+-------------------+
> | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
> +-----------------------+------------------------+-------------------+
> |          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
> |              http://www.ibiblio.org/xml/books/bible2/              |
> |   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
> +----------------------------------+---------------------------------+
> |  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
> |  Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/     |
> +----------------------------------+---------------------------------+
>
> ------------------------------------------------------------------
> The xml-dev list is sponsored by XML.org, an initiative of OASIS
> <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: xml-dev-request@lists.xml.org
>