Subject: [Ltru] Re: two identical singleton extension tags issue

From: "Doug Ewell" <[email-masked]>
Date: Wed, 20 Dec 2006 06:29:52 -0800

Stephane Bortzmeyer <bortzmeyer at nic dot fr> wrote:

>> I recommend that we change the restriction on two identical singleton 
>> extension tags to be a criterion for validity instead of 
>> well-formedness.  This allows programs to test for well-formedness 
>> with a single regular expression,
>
> I disagree with the suggestion. Being able to parse tags "with a 
> single regular expression" does not seem a worthy goal to me, 
> specially since this regexp would be awfully complex 
> (http://unicode.org/cldr/data/tools/java/org/unicode/cldr/util/data/langtagRegex.txt).

+1.  The single (horrible) regular expression strikes me as a neat 
parlor trick, but not much more.

--
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: "Mark Davis" <[email-masked]>
Date: Wed, 20 Dec 2006 08:43:38 -0800

I disagree. The regex is something that, no matter how ugly, you just hand
to someone. They make a one-line call to a regex engine to do it, and they
are done. Well-formedness* is tested. No other code needed, and easy to do
in any language with access to a regex library, such as the following in
Java.

  static final Pattern WELL_FORMED_LANGUAGE_TAG = Pattern.compile("..."); //
... is ugly mess that someone supplies

  static boolean isWellFormedLanguageTag(String tag) {
    return WELL_FORMED_LANGUAGE_TAG.matcher(tag).matches();
  }

Compare that to anyone's code that has to parse everything out and then test
for repeated singletons. I have endless confidence in the ability of
programmers to make errors, so the simpler the better.

Mark

On 12/20/06, Doug Ewell <[email-masked]> wrote:
> > (
> http://unicode.org/cldr/data/tools/java/org/unicode/cldr/util/data/langtagRegex.txt
> ).
>

---

From: John Cowan <[email-masked]>
Date: Wed, 20 Dec 2006 12:02:11 -0500

Mark Davis scripsit:

> I disagree. The regex is something that, no matter how ugly, you just
> hand to someone. They make a one-line call to a regex engine to do it,
> and they are done. Well-formedness* is tested. No other code needed,
> and easy to do in any language with access to a regex library, such
> as the following in Java.

+1

What is more, we should publish the regex in 4646bis so that people can
use it in declarative contexts like XML schemas.

-- 
"But I am the real Strider, fortunately,"       John Cowan
he said, looking down at them with his face     [email-masked]
softened by a sudden smile.  "I am Aragorn son  http://www.ccil.org/~cowan
of Arathorn, and if by life or death I can
save you, I will."  --LotR Book I Chapter 10

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 21 Dec 2006 10:15:43 +0100

On Wed, Dec 20, 2006 at 12:02:11PM -0500,
 John Cowan <[email-masked]> wrote 
 a message of 24 lines which said:

> What is more, we should publish the regex in 4646bis 

-1

Or even -X with X >> 1 :-)

We publish the ABNF, which is the normative definition of the
grammar. Publishing the grammar in yet another format is a recipe for
subtle inconsistencies between them.

May be we could direct people to:

http://cvs.m17n.org/~akr/abnf/

if they want a regexp.

> so that people can use it in declarative contexts like XML schemas.

May be we could suggest a very simplified regexp such as:

[a-z0-9]+(-[a-z0-9]+)* 

(case-insensitive, /i in Perl, re.IGNORECASE in Python)

It would catch most of the stupid mistakes in XML files and be
reasonable readable, although more lax than the real grammar. in the
same way that the XML schema of RFC 4287 suggests the following regexp
for e-mail addresses (whose grammar is beyond the ability of 99.9 % of
mortal programmers):

   # Whatever an email address is, it contains at least one @
   atomEmailAddress = xsd:string { pattern = ".+@.+" }

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 21 Dec 2006 10:24:16 +0100

On Thu, Dec 21, 2006 at 10:15:43AM +0100,
 Stephane Bortzmeyer <[email-masked]> wrote 
 a message of 41 lines which said:

> grammar. Publishing the grammar in yet another format is a recipe
> for subtle inconsistencies between them.

Remember also that there are several regexp languages, not all of them
standardized. I'm not very keen of using Posix (a standard which is
not freely available).

W3C XML Schemas go as far as defining their own regexp language:

http://www.w3.org/TR/xmlschema-2/

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 21 Dec 2006 10:03:37 -0800

Hi -

As a technical contributor...

> From: "John Cowan" <[email-masked]>
> To: "Mark Davis" <[email-masked]>
> Cc: "Doug Ewell" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Wednesday, December 20, 2006 9:02 AM
> Subject: Re: [Ltru] Re: two identical singleton extension tags issue
...
> use it in declarative contexts like XML schemas.
...

I strongly disagree.  We should not be favoring one implementation
technology over another.  Furthermore, as Stephane has pointed out,
this introduces another potential source of errors.  Finally, if you really
really think this would be the right thing to do, please see the constraints in
http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt
on references and completeness.

Randy

---

From: Addison Phillips <[email-masked]>
Date: Thu, 21 Dec 2006 10:28:48 -0800

For a regular expression? Why pseudocode it? I'd suggest a real Perl or 
Java regex. Reference implementations are Very Useful, provided they are 
thoroughly tested and work appropriately.

It might be better to submit ancillary material as a draft targeting an 
Informational RFC. RFC 4646bis is substantial in size as it sits. 
Providing information on implementation separately would probably be 
more useful, not to mention amenable to update.

Addison

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

Internationalization is an architecture.
It is not a feature.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 21 Dec 2006 11:39:30 -0800

Hi -

> From: "Addison Phillips" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>
> Sent: Thursday, December 21, 2006 10:28 AM

A regular expression IS (pseudo)code.
Consequently, we'd need appropriate references for the grammar
and semantics of whichever regular expression dialect you chose,
per http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt

"Reference implementations" do NOT belong in specifications.
They have a nasty way of being treated as normative, and negatively
impact the diversity of the implementation gene pool.  (This is
not as much of an issue for BCP as for standards track, but it would
still concern me.)

...

This sounds like a better approach to me.

Randy