Re: [Ltru] Mail regarding draft-ietf-ltru-4646bis and draft-ietf-ltru-matching

Canonicalizing to the extlang form has a number of disadvantages, and I
would recommend strongly against it. Don't have time to discuss now, will
see about next week.

Mark

On Wed, Aug 28, 2019 at 11:56 AM Florian Rivoal <florian@rivoal.net> wrote:

>
>
> > On Aug 28, 2019, at 2:47, Doug Ewell <doug@ewellic.org> wrote:
> >
> > On July 27, Florian Rivoal wrote:
> >
> >> However, RFC5646 Section 4.5, which defines canonicalization, only
> >> does so for language tags, not for language ranges. Presumably, the
> >> process is largely the same, with wildcards in the language subtag
> >> being preserved, and I suppose wildcards in other subtags would likely
> >> be dropped. But as it stands, that seems undefined.
> >
> > I think you are on the right track by assuming that ranges are
> > canonicalized just like tags, with asterisks left alone.
>
> Thanks for confirming.
>
> > It's not very likely that most LTRU participants will be eager to start
> > up a new IETF project to update 5646 for something like this. Best to go
> > with your assumption.
> >
> >> Also, while giving recommendations about canonicalization for the
> >> purpose of filtering, it would seem useful to mention (and possibly to
> >> recommend) canonicalizing to the "extlang form". The definition of the
> >> extlang form itself (in  RFC5646 Section 4.5) mentions that it is
> >> useful for matching and selecting, but that information isn't relayed
> >> anywhere RFC4647.
> >
> > At the time these documents were written, there was a strong sentiment
> > around de-emphasizing extlangs in general. It's good to know that
> > there's a real-world use case for using them here. Again, it's unlikely
> > that people will want to rev 4647 for this.
>
> The use case is CSS selectors, when writing rules for typography/styling
> in a document. On the one hand, the document gets marked up which part of
> it are in which language. On the other side, the style sheet describes
> which part of the document must be styled which way, and can make that
> styling dependent on the language.
>
> The need for normalization comes from the fact that stylesheet authoring
> and document authoring are not coordinated in the general case, so a
> stylesheet author cannot know, generally speaking, if a document will be
> marked up with, for example, zh-yue or yue. The stylesheet author is then
> faced with two options, both unattractive for different reasons:
> * use the deprecated tag: it's more likely to be found in existing
> documents due to being older. The first downside is that it doesn't always
> work. The second one is that this slows down adoption of the newer
> preferred tag, as document authors wanting to be compatible with existing
> stylesheets will keep on using the deprecated one as well for
> compatibility, and we get into a vicious cycle of everybody continuing to
> use the deprecated variant.
>
> * Use both the deprecated and the preferred tag in the stylesheet's
> selector. This works, but it means that stylesheet authors need to be aware
> of, and manually replicate the information in
> https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry.
> Asking people to manually do what software could isn't great, as they tend
> not to, or to do it with bugs, or to not update when the registry updates,
> etc.
>
> So it seems preferable, given that this correspondence is maintained in a
> neatly usable format, to have CSS renderers deal with the correspondence
> between deprecated and preferred tags by way of canonicalizing to the
> extlang form and doing the selector matching on that.
>
> In the long run, both document authors and stylesheet authors should use
> the preferred tag without the extlang prefix, and the canonicalization to
> extang form will be invisible to them. But even if some don't, everything
> works.
>
> —Florian
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
>