Subject: RE: [Ltru] To XML or not to XML

From: "McDonald, Ira" <[email-masked]>
Date: Fri, 22 Sep 2006 14:57:51 -0700

Hi,

+1 to XML as the *normative* registry format.

All - please answer Martin's question or start a new
thread - half your answers seem to have wandered off
into the unrelated swamp of XML as *informative*,
which is neither interesting nor useful.

If we do shift to XML as *normative*, then I'd urge
that we also ask IANA to continue to make available
the current record-jar format by machine-generation
from the XML format registry.

Cheers,
- Ira

PS - If we 
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> -----Original Message-----
> From: Ned Freed [mailto:[email-masked]]
> Sent: Friday, September 22, 2006 9:32 AM
> To: Martin Duerst
> Cc: [email-masked]
> Subject: Re: [Ltru] To XML or not to XML
> 
> 
> > Dear LTRU WG,
> 
> > We have earlier discussed whether we should move to XML or not
> > for the registry. One unknown in these discussions was what
> > was (or wasn't) going on at IANA.
> 
> > Thanks to David's help, we now have a much better idea of
> > what IANA is up to. Given that information, I'd like us to
> > make a firm decision on whether to use XML or not for RFC464xbis
> > soon. Please (re)state your preference.
> 
> +1 in favor of shifting to XML. I don't think consumption of 
> the current format
> is sufficiently widespread that changing now is going to be a 
> problem. And as
> others have pointed out, an immense array of tools are 
> available for processing
> XML, which may speed up adoption and possibly get us past a few of the
> boneheaded implementation blunders that invariably seem to creep in to
> implementations of newly standardized stuff.
> 
> 				Ned
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru
> 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.12.8/455 - Release Date: 9/22/2006

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

---

From: Addison Phillips <[email-masked]>
Date: Fri, 22 Sep 2006 15:21:12 -0700

Hi Ira,

> which is neither interesting nor useful.

Whenever one has two or more versions of the same thing, it is usually a 
good idea to make one the "normative" version and the others derivative. 
That does not cast aspersions on someone's decision to use the 
derivative copy, especially if the two are carefully synchronized.

In this case, we have registration forms, a registry format, and a 
process for creating and maintaining the list of valid subtags using the 
record-jar format. Changing to XML would require that each of these 
items be examined and aligned with the new format. We will also have to 
define the document structure, and create steps for validating the 
registry, and so forth.

I have nothing against XML as a format for the registry. In fact, I 
think it was, originally, my idea. But I'm not in favor of doing a 
massive revision to RFC 4646 within weeks of its publication just so was 
can have a different file format. My suggestion (a third option) would 
avoid many of the problems above by keeping record-jar as the "official" 
format, but requiring IANA to maintain an XML copy in a particular 
format and synchronized with the "normative" source. If done properly, 
it will be indistinguishable from being a "normative reference" in its 
own right.

I note that ISO 639 keeps tables on their web sites and many of us refer 
to those when looking up items (at least, until the advent of the 
LSTR!!), even those those references are far from "normative".

In "wandering off into the unrelated swamp", I am attempting to have my 
cake and eat it too: I would like to see an XML *copy* of the registry, 
but I think it ill-timed and not an immediate requirement that we do it 
in 4646bis. I think this is a useful compromise. As described above, 
would this pose a problem for you? And if so, why?

> from the XML format registry.

Isn't this precisely the converse of my proposal? The record-jar would 
be "informative" and the XML "normative" in this case...

Best Regards,

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 23 Sep 2006 00:47:48 +0200

Addison Phillips wrote:

> I'm not in favor of doing a massive revision to RFC 4646
> within weeks of its publication

+1 (putting it very mildly)

> I would like to see an XML *copy* of the registry

<http://purl.net/xyzzy/home/ltru/lstreg2.xml> is a new attempt,
I've given up on "mixed content".  The XML spec. is very hard
to read with non-UTF-8 browsers.

> I think it ill-timed and not an immediate requirement that
> we do it in 4646bis.

BTW, lstreg2.xml is now 140 KB based on 80 KB in lstreg9.txt,
75% more.  For the 640 KB input I get over 1 MB, and that's a
*TILT* as discussed in the 4646 round.

Frank

---

From: "Felix Sasaki" <[email-masked]>
Date: Sat, 23 Sep 2006 08:40:02 +0900 (JST)

> Hi Ira,

[snip]
> in 4646bis. I think this is a useful compromise.

+1

Felix