Subject: RE: [Ltru] Re: Registry in record-jar format

From: "Addison Phillips" <[email-masked]>
Date: Thu, 24 Mar 2005 05:32:55 -0800

We can change the definition of a text-based version of the registry to use UTF-8, although that imposes a certain burden on users that a string ASCII regime does not. (Did I write that? I cannot believe I'm defending an ASCII solution for this...)

XML uses Unicode by definition, although we might choose to restrict the registry file's actual encoding to ASCII for similar reasons.

The question about lots of non-ASCII (JFC's comment) is a spurious one: by rule it should be limited to the name of the described language or language part in that language or to descriptive fields (both informative). The normative data would still be restricted to ASCII.

I agree that the initial registry need not be RFC text per-se. I do note that there is no reason that the initial registry *values* couldn't be listed in one format (say record-jar) and the normative registry itself be in another (such as XML).

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jon Hanna
> Sent: jeudi 24 mars 2005 03:55
> To: [email-masked]
> Subject: RE: [Ltru] Re: Registry in record-jar format
> 
> > The resulting plain text ASCII RfC and registry could be messy,
> > from the POV of a reader.  One or two literal &#1234; or u+04D2
> > in a paragraph are okay, but numerous of these beasts are ugly.
> 
> It would (and I'd hope eventually will) be much nicer if the RFC rules
> allowed for UTF-8 wouldn't it?
> 
> Still, I'd imagine that the said XML section would be an appendix that
> anyone studying in earnest would view as XML, rather than as ASCII source
> formatted to fit the RFC line-width rules, so I don't foresee this being a
> major issue.
> 
> Regards,
> Jon Hanna
> Work: <http://www.selkieweb.com/>
> Play: <http://www.hackcraft.net/>
> Chat: <irc://irc.freenode.net/selkie>
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 24 Mar 2005 15:25:12 +0100

At 14:32 24/03/2005, Addison Phillips wrote:
>The question about lots of non-ASCII (JFC's comment) is a spurious one: by 
>rule it should be limited to the name of the described language or 
>language part in that language or to descriptive fields (both 
>informative). The normative data would still be restricted to ASCII.

I am always happy to read constructive comments. Obviously ASCII fits the 
ASCII Internet. The question is will it fit the Multilingual Internet we 
all work on?

I am just interested to know if what you consider spurious is "non-ASCII" 
or "lots". And if you think user's descriptive fields MUST or SHOULD be in 
ASCII (obviously only a MUST would go your way). Also, when you speak of 
normative data, do you speak of normative codes and numbers or of all the 
data in the norm, i.e. including French texts, (and happily sometimes, for 
the language norms Chinese, Russian, Arabic, etc. will be supported - again 
only a question of budget and international agreements we do not control)? 
ASCII will not even fully support French which is a normative language.

jfc

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 25 Mar 2005 04:10:46 +0100

Addison Phillips wrote:

> Did I write that? I cannot believe I'm defending an ASCII
> solution for this...

<g>  There's nothing wrong with ASCII, it works everywhere.

> XML uses Unicode by definition, although we might choose to
> restrict the registry file's actual encoding to ASCII for
> similar reasons.

Let's say that we don't want any "language name in its native
script(s)" at the moment for 3066bis, it should be possible to
add it later.  IIRC Bruce wanted the official French names in
the relevant standards, but IMHO that leads nowhere - national
organizations are free to create their own official translations
of the registry.

> there is no reason that the initial registry *values*
> couldn't be listed in one format (say record-jar) and the
> normative registry itself be in another (such as XML).

Both formats are important, for 3066bis we don't need to decide
which form is "normative" and which is "derived", if we stick
to ASCII.  Only for more Unicode points XML is probably better.

Doug now has scripts to create the format with six columns, on
his system both XML and record-jar would be "derived" formats.

I don't see a problem with this, let's discuss potential DTDs.

Later you could add a DTD as appendix, and use the record-jar
field names in the text, if that's the shortest and simplest
way to define the semantics.
                            Bye, Frank