Subject: RE: [Ltru] massaging and moving 'length considerations' (#944)

From: "Addison Phillips" <[email-masked]>
Date: Thu, 23 Jun 2005 09:52:19 -0700

Some comments below. Basically, I think that length considerations is in the wrong section out of a misguided desire to "feature" this particular issue.

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: McDonald, Ira [mailto:[email-masked]]
> Sent: 2005?6?23? 9:39
> To: Addison Phillips; Martin Duerst; Randy Presuhn; LTRU Working Group
> Subject: RE: [Ltru] Can we live with #944 as in draft -05? (yes, BUT)
> 
> Hi Addison,
> 
> Well...the new subsections don't even show in the Table of Contents
> (because they're at the fourth level).
[Addison Phillips] 

Yes. There are limits to what we can do on that level, although probably I can make the TOC reflect additional sectional granularity. The most logical thing, actually, would be to move this sub-section to where it logically belongs in the document (part of Section 4, which is about formation and processing of language tags---it is out of place in the section on syntax, IMHO).

> 
> What I'd like to see (details of text aside) is:
> - A numbered section in the Table of Contents named something like
>   'Tag Length Conformance Requirements' (not 'Assigning...')
[Addison Phillips] 

I disagree. Nothing else is titled this way in the whole document. Calling out this particular issue (already a facet of language tags, please note) is not instructive, I feel. After all, the document must be read and understood and length limitations do not exist in a vacuum.

> - That old <para 5> broken up, because it still buries the
>   key conformance requirement of the whole spec in obscurity.
[Addison Phillips] 

I disagree: it is not "in obscurity". It is in a logical progression of text. If you read this section you will see the requirements and, because they are in context, understand why they are there.

To call them out, I could turn them into bullet points in a list. Would that make them sufficiently visible?
> 
> Cheers,
> - Ira
> 
> 
> 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: [email-masked]
> > [mailto:[email-masked]]On
> > Behalf Of Addison Phillips
> > Sent: Thursday, June 23, 2005 12:13 PM
> > To: Martin Duerst; Randy Presuhn; LTRU Working Group
> > Subject: RE: [Ltru] Can we live with #944 as in draft -05? (yes, BUT)
> >
> >
> > >  >> Please add a short intro paragraph to Chapter 2.
> >
> > I've thought about this some more...
> >
> > I've done the following as a result:
> >
> > 1. I simplified the text in the introduction with more
> > reliance on the word "tag".
> >
> > 2. I moved the definition of language tags from Section 4.2
> > (meaning) to act as an introduction to the language tag in
> > Section 2 (just before Section 2.1). Section 4.2 has been
> > slightly reorganized as a result (the "meaning" material was
> > moved ahead of the prefix relationship material).
> >
> > 3. Following Ira's note, I have added more structure and some
> > gentle word tugging to Section 2.1.1 (length considerations)
> > and fixed the pedantic "divided" as noted by Martin. There
> > are now two subtags for that section ("Assigning Buffer
> > Limitations" and "Truncation of Language Tags")
> >
> > 4. I changed to use the symrefs='yes' processing instruction.
> > References should now be somewhat cleaner.
> >
> > Results on-line at inter-locale. If no objections result,
> > I'll post an official draft-06 today.
> >
> > 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: Martin Duerst [mailto:[email-masked]]
> > > Sent: 2005?6?23? 1:31
> > > To: Addison Phillips; Randy Presuhn; LTRU Working Group
> > > Subject: RE: [Ltru] Can we live with #944 as in draft -05?
> > (yes, BUT)
> > >
> > > Sorry for the delay. Here are some replies. The rest is
> > fine with me.
> > >
> > > At 12:46 05/06/21, Addison Phillips wrote:
> > >  >Some notes below.
> > >  >
> > >  >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 Martin Duerst
> > >  >> Sent: 2005?6?20? 18:21
> > >  >> To: Randy Presuhn; LTRU Working Group
> > >  >> Subject: Re: [Ltru] Can we live with #944 as in draft
> > -05? (yes, BUT)
> > >  >>
> > >  >> At 08:38 05/06/21, Randy Presuhn wrote:
> > >  >>  >Hi -
> > >  >>  >
> > >  >>  >I'd like to see whether we can close issue #944
> > regarding whether
> > >  >>  >a conformant implementation can impose length
> > constraints and what
> > >  >>  >those constraints might be.  So I'd like to get a
> > "hum" from the
> > > group:
> > >  >>  >
> > >  >>  >Can you live with the resolution of this issue are
> > reflected in
> > >  >>
> > >http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-05.txt ?
> > >  >>  >
> > >  >>  >As you may recall from the discussion, points of
> > concern included
> > >  >>  >whether the MUSTs and SHOULDs made sense,  whether the
> > >  >>  >lengths given were meaningful, and whether the
> > underlying rationale
> > >  >>  >was sufficiently clear.
> > >  >>
> > >  >> Overall, I'm quite satisfied.
> > >  >>
> > >  >> But here are a few, mostly editorial, nits:
> > >  >> (for Randy: I think all these can be lumped together unless
> > >  >> somebody wants to have one of them addressed specifically).
> > >
> > >
> > >  >> -05.txt says:
> > >  >>     and such
> > >  >>     documentation SHOULD include the disposition of any
> > longer tags
> > > (for
> > >  >>     example, whether an error value is generated or the
> > language tag
> > > is
> > >  >>     truncated).
> > >  >> I don't like the use of a noun that then gets expanded into a
> > > 'whether'
> > >  >> sentence. Maybe:
> > >  >>     and such
> > >  >>     documentation SHOULD include what happens to longer
> > tags (for
> > >  >>     example, whether an error value is generated or the
> > language tag
> > > is
> > >  >>     truncated).
> > >  >[Addison Phillips]
> > >  >
> > >  >That's a no-op change, if there ever was one. It's good
> > because it drops
> > >  >the rather convoluted "disposition" in favor of the more
> > Anglo-Saxon
> > >  >phrasing you suggest. I'll make this change.
> > >
> > > First time somebody has called a proposal of mine
> > "Anglo-Saxon phrasing".
> > > Delighted to hear that!
> > >
> > >  >> -05.txt says:
> > >  >>     If truncation is permitted it MUST NOT permit a subtag to be
> > > divided
> > >  >>     or the formation of invalid tags (for example, one
> > ending with the
> > >  >>     "-" character).
> > >  >> please at least reword to:
> > >  >>     If truncation is permitted it MUST NOT permit a subtag to be
> > > divided
> > >  >>     or an invalid tag to be formed (for example, a tag
> > ending with the
> > >  >>     "-" character).
> > >  >> Also, I'm not sure why we need two things (divided,
> > formed) here.
> > > Wouldn't
> > >  >> the later just be enough?
> > >  >[Addison Phillips]
> > >  >
> > >  >Divided is, to be sure, a special case of invalid. But a
> > divided subtag
> > >  >might be valid per the ABNF--or even the registry. It
> > makes sense to
> > > call
> > >  >out the special case of not chopping mid-tag.
> > >
> > > "not chopping mid-tag" is much easier to understand (but
> > maybe not yet
> > > as formal as the rest of the draft) than "divided".
> > >
> > >  >> An even more serious problem is that section 1 speaks
> > about language
> > >  >> identifiers, and the word 'tag' doesn't appear a single
> > time in that
> > >  >> section. Please add something at the end of section 1
> > saying that
> > >  >> this document defines a language tag that is designed
> > to serve as
> > >  >> a language identifier. Or even better, use the stem 'identif...'
> > >  >> just for the purpose, and the word 'tag' for the thing,
> > as done in
> > >  >> the title.
> > >  >[Addison Phillips]
> > >  >
> > >  >This text is more-or-less inherited. Must we remove all
> > vestiges of
> > >  >Harold's authorship?
> > >
> > > Of course not. But if that's from RFC 3066, then I have to apologise
> > > to Harald that I didn't comment on that earlier.
> > >
> > >  >But I'll be sufficiently creative to spell out that a
> > >  >tag is an identifier... :-)
> > >  >>
> > >  >> Also, please give Section 2.1 more structure. If there
> > are subsections,
> > >  >> good style requires that almost everything (except a
> > relatively short
> > >  >> intro piece) is a subsection, and that there are at
> > least two of them.
> > >  >> The easiest thing to do is to make the ABNF 2.1.1, and
> > the length
> > >  >> stuff 2.1.2.
> > >  >[Addison Phillips]
> > >  >
> > >  >No. Section 2 has plenty of structure.
> > >
> > > Section 2 as such has enough structure. The problem is with
> > Section 2.1.
> > > Please fix.
> > >
> > >  >> Please add a short intro paragraph to Chapter 2.
> > >
> > >  >> References such as [RFC 2231] [23] look extremely ugly.
> > Please make
> > > this
> > >  >> either [RFC 2231] or [RFC2231] only (my strong preference) or
> > > something
> > >  >> like RFC 2331 [23].
> > >  >[Addison Phillips]
> > >  >
> > >  >I'll look into it. I have developed a strong aversion to
> > xml2rfc. W3C
> > >  >Specifications are much cleaner.
> > >
> > > I got that problems solved for IRIs (RFC 3987). The source is one
> > > click away from http://www.w3.org/International/iri-edit.
> > >
> > >  >> I'm not sure zh-Hant-CN-variant1-a-extend1-x-wadegile
> > makes a good
> > > example.
> > >  >> Wade-Giles is a romanization, one would therefore expect zh-Latn
> > > rather
> > >  >> than
> > >  >> zh-Hant.
> > >  >[Addison Phillips]
> > >  >
> > >  >This example was taken from a particular thread "early"
> > on in this WG's
> > >  >life. Since it is a private use tag, any sort of
> > illogical garbage might
> > >  >exist. That said, "zh-latn-CN-variant1-a-extend1-x-wadegile" would
> > > actually
> > >  >make some sense, wouldn't it?
> > >
> > > Fine with me.
> > >
> > >
> > > Regards,    Martin.
> >
> >
> >
> > _______________________________________________
> > Ltru mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ltru
> >

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