Shawn Steele wrote: > +1 on reaching a resolution. > > Unlike Mark, I think that some new ideas have surfaced since this was discussed, and I understand Karen's frustration with original discussion. Like Mark, I'd like to get this thing done because I have deadlines and products that will depend on whatever's decided here. I want to make sure its something everyone in the industry can feel OK about. > > As most of you know, I personally supported extlang. Very recently, Peter & I (& others here at Microsoft) convinced each other that extlang wasn't really necessary and I felt that the concepts of "lists" would perhaps address my concerns regarding matching. > > Since then there has been discussion about the lack of "lists" in some standards/contexts and how that might make it difficult for applications to correlate zh & yue in a document's tags if necessary. Now I find myself wondering if maybe extlang makes sense again for some cases, but, even worse, it seems to me that zh, cmn AND zh-cmn should be legal to properly tag some documents (Chinese of some form, known Mandarin, and Mandarin that's also acceptable for general Chinese use would be my interpretation). So now I'm pretty neutral. I'm reasonably convinced that extlang isn't necessary for my immediate concerns, however if I try to consider Karen's and other scenarios besides my own immediate problems, perhaps extlang would be better. > > One thing I'm very certain of is that zh != cmn and the standards shouldn't make an unnecessary correlation that doesn't exist in practice. > > I'm also disconcerted that Karen feels this effort may not address her needs because I don't want a disconnect between A/V standards that might be useful for on-demand content and other software on the system. Everyone's needs certainly aren't the same, but information is getting more and more connected and these things show up in odd places. > I too hope very much that this discussion will lead to a result which will be satisfactory for Karen's use case - also to be able to ensure the applicability of xml:lang in her community. Felix > - Shawn > > ________________________________________ > From: ltru-bounces at ietf.org [ltru-bounces at ietf.org] On Behalf Of Karen_Broome at spe.sony.com [Karen_Broome at spe.sony.com] > Sent: Friday, May 09, 2008 5:05 PM > To: Mark Davis > Cc: LTRU Working Group > Subject: Re: [Ltru] extlang or not extlang > > The extlang decision was mostly made on ill-announced conference calls, > not the list. While you may feel you discussed this to death, some of us > feel bullied. There must be some new information as we've changed the > draft as a result of recent discussion and our recommendation for the > world's most popular language. Your recent statement that it would be > better if "cmn" was deprecated was totally shocking to me. The suggestion > that "in practice" zh should be treated as Mandarin is an affront to > non-Mandarin Chinese languages and will create problems. I believe there > are at least four or five longtime followers of this work who are not > totally comfortable with this decision. > > I'm starting to think it would be better for my needs if RFC 4646bis was > never released. While this may not be true for everyone, RFC 4646bis now > does not add anything that I personally need and it changes the semantics > of tags I already use. I do not want to see the "zh" tag narrowed "in > practice" as that would mean I can't trust any "zh" tag to mean what I > think it means. I'm not even 100% sure where we stand on Chinese languages > now and this affects how I feel about extlang. I am afraid I will regret > putting the words "RFC 4646bis or its successor" into numerous A/V > standards now that I see ISO 639-6 nearing completion and the unexpected > turn in the direction of this work. > > This update could be a death knell for xml:lang as I don't think > developers will be able to follow these guidelines consistently. > > Regards, > > Karen Broome > Sony Pictures Entertainment > > > > > ltru-bounces at ietf.org wrote on 05/09/2008 03:55:03 PM: > > >> I'm completely opposed. >> >> We spent a long time reviewing all of the issues before coming to a >> way to move forward on the extlang issue. There has been no new >> information that was not available at the time we made the decision. >> It was a very long and involved process. While there are advantages >> and disadvantages to both sides, I see no reason to believe that we >> would come to a different conclusion, and it would undoubtedly take >> a similar amount of time before we come to resolution. I have >> refrained from responding to those suggesting that extlang was the >> solution just so as to not complicate the issue, because I really >> don't think we want to go through that process again. >> >> The way that the current text reads, it is absolutely trivial for >> those who want to support particular macrolanguage fallbacks to do >> so, and it does not end up with the fallback in the many, many cases >> where it leads to worse results. >> >> Reopening the issue will delay us for no good reason. We have spent >> long enough on 4646bis, it is time to get this revision out. >> >> Mark >> > > >> On Fri, May 9, 2008 at 8:44 AM, Phillips, Addison <addison at amazon.com> >> > wrote: > >> Co-chairs, >> >> It seems we have arrived back at an impasse. I still think not >> having extlang is the correct course. >> >> I would not be opposed to restoring extlang, if that is the >> consensus of the group and provided it can be done expeditiously. >> >> Can you please institute some process for resolving this issue-- >> either closing off the reappearance of extlang or deciding to >> restore it and focusing on completing the draft in the next few >> weeks under that banner. >> >> Addison >> >> Addison Phillips >> >> Internationalization is not a feature. >> It is an architecture. >> >> >> _______________________________________________ >> Ltru mailing list >> Ltru at ietf.org >> https://www.ietf.org/mailman/listinfo/ltru >> >> >> >> -- >> Mark _______________________________________________ >> Ltru mailing list >> Ltru at ietf.org >> https://www.ietf.org/mailman/listinfo/ltru >> > > > _______________________________________________ > Ltru mailing list > Ltru at ietf.org > https://www.ietf.org/mailman/listinfo/ltru > _______________________________________________ > Ltru mailing list > Ltru at ietf.org > https://www.ietf.org/mailman/listinfo/ltru > _______________________________________________ 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.