> > For X-Y-Z (Z being some string) and Y-Z, then X-Y-Z and Y-Z is > always a match, but (c) whether X-Z and Y-Z are matched is a > separate matter. X-Z and Y-Z would match in *extended* filtering if X-Z is the range and Y-Z is equivalent to X-Y-Z, but at no other time. It is useful to note that in lookup, you cannot obtain the Y-Z resource itself by requesting X-Z. You can obtain its parent resource X if you canonicalize to X-Y-Z and then fall back, but not Y-Z (or even X-Y-Z). In basic filtering you can never obtain Y-Z by requesting X-Z. Neither can you obtain X-Z by requesting Y-Z (or X-Y-Z). As a reminder of why: consider Suppress-Script. > > > > I assume that this proposal is still in the context of only > allowing a > > small number of macrolanguages (plus 'sgn') as Xs in X-Y? > > That choice is left open. Part of what I was saying is that I think > there's less potential need to consider cherry picking in that > particular regard for #3 than there is for #1 or #2: since X-Y and > Y equivalence would be guaranteed, then there really isn't a need > to say up front that only a small set of macrolanguages are > candidates for X. > Multiple tag choices for the same meaning are Bad News, regardless of what form they take. We should create a few as possible (but no fewer). The "equivalence guarantee" you seek is, I fear, fraught with implementation headaches, since it requires interior knowledge of the subtag registry in order to work. Addison _______________________________________________ Ltru mailing list Ltru at ietf.org https://www.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.