<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 5/22/2014 1:12 PM, Asmus Freytag
wrote:<br>
</div>
<blockquote cite="mid:537E5A3C.1090101@ix.netcom.com" type="cite">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<span
style="font-family:"Candara","sans-serif"">LGR
list members,<br>
<br>
the requirement that the LGRs created by the Generation Panels
must be submitted in the new XML Format For Representing Label
Generation Rules <link> continues to be the cause of some
apprehensions.<br>
</span></blockquote>
<br>
The link is <a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/draft-davies-idntables-07">http://tools.ietf.org/html/draft-davies-idntables-07</a> for
the latest rev of the specification.<br>
<blockquote cite="mid:537E5A3C.1090101@ix.netcom.com" type="cite"><span
style="font-family:"Candara","sans-serif"">
<br>
My intent with this message is to start a discussion and perhaps
help dispel some of these apprehensions.<br>
<br>
The MSR drafted by the integration panel contains an XML file,
that lists the repertoire of the MSR in the XML format. If your
Generation Panel does NOT support variants and does NOT support
script-specific WLE rules, the simplest way to generate the
required XML file might be to delete from the MSR all entries
that are not included in your LGR.<br>
<br>
A more generic approach would be to use a plain text file in a
private format to list the code points and variants to do all
the editing. This file could be in one of the several existing
format for IDN tables. <br>
<br>
Because <i>generating </i>XML is much easier than <i>editing
</i>XML, the approach that we followed in creating the MSR is to
do our editing in such a private format, and then to use a short
Perl script to generate the XML from that. <br>
<br>
By doing this, we avoid introducing the kinds of XML errors that
are the result of hand-editing an XML file.<br>
<br>
For those scripts that use variants on the second level today,
existing IDN tables have ways to express variants, and these can
be converted to the new format by a Perl script as well. The
effort required is quite moderate. If I may, I'd like to refer
to my own experience. For a different ICANN project, I managed
to write a functioning reader in a full-fledged programming
language (not a script language) in about a week, supporting not
just one IDN table format, but as many formats as existed in the
IANA registry. To write the method that outputs the same data in
XML format took some additional time.<br>
<br>
I assume that most GPs already have draft repertoire lists that
could be converted to the same format as the MSR, and a simple
diff could be used to find out whether the draft repertoire
accidentally contains code points not allowed in the MSR.
Alternatively, there are many tools that read XML files and can
translate them into columnar tables. MS- Excel can do that, for
example. Once saved in .CSV format, such tables are simple to
transform into whatever private format your GP has decided to
use for editing.<br>
<br>
Either way, you will have your draft data in a format that you
are familiar with while you are editing, and a format that is
easily compared to both your starting collection (the one you
derived from the MSR intersected by your script) and to later
versions of your draft repertoire.<br>
<br>
Now, when it comes to creating whole label evaluation rules, no
such shortcuts exist. What I would propose is that any
Generation Panel that intends to define such rules, create a
detailed description with regular expressions or pseudo code (as
in RFC 5892 for example). Those of us who are more familiar with
the format would then be able to assist you in translating these
rules into the XML format.<br>
<br>
The resulting XML for the rules can be appended by script to the
part that is created from the plain text list of repertoire and
variants. That way, your Generation Panel can continuously have
an updated draft of its complete LGR in the XML format without
doing any actual XML editing.<br>
<br>
Finally, there is the matter of validation and correctness of
the XML specification. If your GP produces XML drafts according
to these suggestions, it would be a simple matter to assist the
GPs in making sure that the XML is valid and satisfies any other
restrictions that are specific to the Root Zone LGR work. It's
not clear whether those tools that Integration Panel members
wrote for our own purposes on the panel can be shared, or
whether ICANN staff at this time has a tool that is shareable,
but I know this is being looked into.<br>
<br>
Until then, we can always run any early LGR drafts that are
shared with us through our tools and report any issues. The main
goal is to make sure that no LGR is rejected based on a simple
typo or syntax error.<br>
<br>
A./<br>
Asmus Freytag</span> <br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
lgr mailing list
<a class="moz-txt-link-abbreviated" href="mailto:lgr@icann.org">lgr@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/lgr">https://mm.icann.org/mailman/listinfo/lgr</a>
</pre>
</blockquote>
<br>
</body>
</html>