Subject: [Ltru] Re: XML format registry?

From: "Doug Ewell" <[email-masked]>
Date: Sun, 22 Jul 2007 16:46:19 -0700

David Conrad <david dot conrad at icann dot org> wrote:

> On Jul 21, 2007, at 10:02 PM, Randy Presuhn wrote:
>> I look at it a little differently.  IANA is already moving to XML for 
>> its registries.  Its a question of whether we want to have some say 
>> in what the XML representation looks like, or whether we're confident 
>> that what IANA decides on will be as good as anything we might come 
>> up with, and that the developer community that uses the registry is 
>> better served by keeping the modified record-jar format as well.
>
> We'll be soliciting input on the XML representation (and transforms to 
> the "legacy" ASCII text table format) of the various registries from 
> anyone who cares, and in particular, the working groups (or other 
> interested parties) responsible for the registries.

On Wed, 20 Sep 2006 08:18:23 -0700, David wrote in response to Frank 
Ellermann:

> To clarify, the XML-ization of IANA registries is an _internal_ 
> effort, primarily aimed at allowing us to simplify/automate registry 
> creation and modification.  We will take what efforts we can to insure 
> there is no significant change to the "legacy" registries.
>
> ...
>
>> Google didn't find what you said in January, but apparently half of 
>> the IAB should have known that that's coming, and not a minor issue.
>
> Actually, I believe it is a minor issue (at least from an external 
> perspective).

Has there been a change in IANA's position, or is it still the case that 
the XML-ization of IANA registries is meant to be an internal effort and 
not intended to affect the way end users see them and WGs define them?

As long as IANA can maintain the Language Subtag Registry in accordance 
with RFC 4646 (and eventually 4646bis) and can correctly process the 
changes submitted by ietf-languages, it makes absolutely no difference 
whether they use XML internally, or which XML schema they choose.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages

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

---

From: David Conrad <[email-masked]>
Date: Mon, 23 Jul 2007 08:34:17 -0500

Doug,

On Jul 22, 2007, at 6:46 PM, Doug Ewell wrote:
> Has there been a change in IANA's position, or is it still the case  
> that the XML-ization of IANA registries is meant to be an internal  
> effort and not intended to affect the way end users see them and  
> WGs define them?

Sorry if I added any confusion.  There hasn't been a change.  The  
XMLization is an internal effort, but we're not proud and beg for  
help from pretty much anyone on the best way to set up the XML  
stuff.  We will be publishing the XML _in addition to_ the RFC- 
specified and/or "legacy" registries.

Rgds,
-drc

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 23 Jul 2007 07:41:29 -0700

David Conrad <david dot conrad at icann dot org> wrote:

> XMLization is an internal effort, but we're not proud and beg for help 
> from pretty much anyone on the best way to set up the XML stuff.  We 
> will be publishing the XML _in addition to_ the RFC-specified and/or 
> "legacy" registries.

I didn't know the last part.  That means we probably do need to be 
involved in determining the XML format, and probably need to specify 
that both XML and record-jar versions are normative.  The first, 
unfortunately, will probably delay us even further as the "entities vs. 
attributes" wars heat up.

---

From: Addison Phillips <[email-masked]>
Date: Mon, 23 Jul 2007 09:33:08 -0700

> that both XML and record-jar versions are normative.

No, we don't.

IANA can have their little project (it won't help them much with the 
ILSR, since everything is done in terms of record-jar).

Note that the XML version doesn't have to be normative. Co-normative 
formats are almost always a Bad Idea. Unless we change the registry 
format itself to an XML format, it must remain derivative.

That is not to say that a derivative copy of the registry has no use, 
only that it is not the normative copy.

I utterly, completely, totally, wholly oppose changing to XML at this 
time. Let's finish 4646bis. Let's not make the document longer just to 
have another format. Let IANA deal with XMLification. I'm sure that many 
of us will be glad to help with the element/attribute fun.

Addison

PS> Long-time participants in this forum will note the irony here. I was 
the one who originally proposed and fought for XML as the registry 
format and UTF-8 as the encoding of the registry. In recent weeks I have 
played the villain, opposing both. Bwah-ha-ha-ha-ha.

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.

---

From: Peter Constable <[email-masked]>
Date: Mon, 23 Jul 2007 13:05:29 -0700

Might it make sense to make XML-ization a follow-on project to RFC4646bis? Is it in the current charter? (I know: I could go look. Just raising questions.)

Peter

---

From: "Debbie Garside" <[email-masked]>
Date: Mon, 23 Jul 2007 22:14:18 +0100

I think that would be a wise thing to do rather than delaying the current
RFC.  So +1 to this and +1 to Doug where he said it was too much of a
rapid-fire decision to make right now.

Debbie

> From: Peter Constable [mailto:[email-masked]] 
> Sent: 23 July 2007 21:05
> To: Doug Ewell; LTRU Working Group
> Subject: RE: [Ltru] Re: XML format registry?
> 
> Might it make sense to make XML-ization a follow-on project 
> to RFC4646bis? Is it in the current charter? (I know: I could 
> go look. Just raising questions.)
> 
> 
> Peter
> 
> 
> 
> I didn't know the last part.  That means we probably do need 
> to be involved in determining the XML format, and probably 
> need to specify that both XML and record-jar versions are 
> normative.  The first, unfortunately, will probably delay us 
> even further as the "entities vs.
> Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  
> UTN #14 http://users.adelphia.net/~dewell/

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 23 Jul 2007 22:38:04 -0700

> format itself to an XML format, it must remain derivative.

I understand that, and why, parallel normative formats are bad.  If IANA 
is OK with having record-jar be normative and XML be informative, that 
is fine with me.  If, however, IANA considers the XML version to be 
"more official," or if users think it is "more official" because of the 
perception that "IANA is converting all their registries to XML," then 
we may have a problem.

> have another format. Let IANA deal with XMLification. I'm sure that 
> many of us will be glad to help with the element/attribute fun.

+1, conditioned by what I said above.

> PS> Long-time participants in this forum will note the irony here. I 
> was the one who originally proposed and fought for XML as the registry 
> format and UTF-8 as the encoding of the registry. In recent weeks I 
> have played the villain, opposing both. Bwah-ha-ha-ha-ha.

I didn't think you were opposing UTF-8 outright so much as raising a 
legitimate issue (allowing non-ASCII breaks processors that conform 
strictly to the grammar).  I raised some potential issues myself, as 
advocatus diaboli, yet still strongly support UTF-8.

Peter Constable <petercon at microsoft dot com> wrote:

> Might it make sense to make XML-ization a follow-on project to 
> RFC4646bis? Is it in the current charter? (I know: I could go look. 
> Just raising questions.)

If you are suggesting that we make plans to convert the normative 
Registry to XML in the future, a very good question to ask would be, 
"Why didn't they just do that when they were already reviewing it?"

I don't think we should change the format unless there is a discernible, 
practical demand for change.  Right now we don't have that.  We have a 
group of file-format wonks (a badge I wear with pride) arguing about 
which format is "best," but nobody has presented a serious, practical 
problem with the existing format that switching to XML would cure.  By 
contrast, there have been real-world arguments against the hex NCRs 
(mostly that they're not human-readable) that switching to UTF-8 would 
cure.

BTW, the LTRU charter does say:

"The working group... may also make adjustments to the registration 
process and the form of the registry if this is deemed appropriate based 
on ongoing registration and operational experience. These adjustments 
and clarifications are not expected to delay the progress of the work."

These "adjustments" could indeed amount to changing the Registry to XML 
if we deemed it appropriate.  I don't know what to say about delaying 
the progress, since we're at least seven months behind already.

---

From: David Conrad <[email-masked]>
Date: Tue, 24 Jul 2007 09:43:25 +0200

On Jul 23, 2007, at 9:41 AM, Doug Ewell wrote:
> involved in determining the XML format, and probably need to  
> specify that both XML and record-jar versions are normative.  The  
> first, unfortunately, will probably delay us even further as the  
> "entities vs. attributes" wars heat up.

Err, no.  IANA's XMLization effort should not cause any working group  
to delay their efforts.

Where an RFC or tradition dictates a particular format (e.g., "record  
jar") that cannot be trivially transformed, the non-XML format will  
be the normative format for the foreseeable future.  For  
consistency's sake, IANA may attempt to transform the normative  
format to XML, but if that is not possible, we'll just let things be.

To be clear, we're trying to improve things, not make things harder  
for folks.

Rgds,
-drc

---

From: Peter Constable <[email-masked]>
Date: Tue, 24 Jul 2007 01:15:40 -0700

> practical demand for change...

Let me put my comment another way, then:

If anybody thinks we should XML-ize the LSTR, then I'd suggest that they propose that for a follow-on project. If anybody asks why we didn't do it this time, we can say, "Because there was no immediate need, the revisions that were done required quite a bit of time as it was, and hence we thought it best to get those revisions completed rather than delay to pursue the possibility of a conversion to XML and all of the issues that would raise."

> I don't know what to say about delaying

We don't want to drag it out further.

Peter