[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re[3]: [cgmo-webcgm] Issue CL-c1: requirements contradiction between two paragraphs
Wednesday, March 22, 2006, 6:57:48 PM, you wrote: > At 05:15 PM 3/22/2006 -0500, Benoit Bezaire wrote: >>Wednesday, March 22, 2006, 5:04:58 PM, you wrote: >> >> > Thoughts? What, if anything, should we do about it? >>Ask CL for some explanations regarding the contradiction. You and I >>have different interpretation of what he meant... > I'm lost. I didn't realize that you and I were disagreeing about > what he meant! The text you wrote to me sounded like we were in disagreement. > (In fact, I agree with CL's observations about the problems in the > two quoted paragraphs.) If you re-read your assessment, you don't say that you agree with CL. > First, let's make sure we're on the same page. The first two paragraphs of > CL-c1 (the blockquote, "[[[...]]]") are from our "2.0 Requirements" > document [1]: > [1] > http://www.oasis-open.org/committees/download.php/14243/WebCGM_20_Requirements.html > They're not Chris's words, they're our words. I know that. > Chris points out that the 1st quoted paragraph seems to enable > unicode in URIs, and the 2nd quoted paragraph seems to disable it. Yes. > I agree with Chris, that's how the two paragraphs appear (if the 2nd > paragraph is lacking the background and motivation that led to it, > which is indeed the case) Still... even if you clarify the 2nd paragraph... we have the situation where the 1st says we support unicode and the 2nd says, well not a 100% true, we support unicode but not in links. > In my preliminary analysis, and in my email below, I'm trying to > explain how the 2nd paragraph somewhat missed our intention, which > was NOT to disable unicode use in links. Rather, it was intended to > preserve the 1.0 status quo, and to help us try to avoid the huge > amount of time that questions of i18n, charmod conformance, etc. can > consume (as witnessed by another s.v.g. in another venue.) That wasn't clear to me. > I guess we need to straighten this out in telecon -- I seem to be > missing your point. I think we are getting back on the same page. > -Lofton. >>-- >>Regards, >> Benoit mailto:benoit@itedo.com >> >>This e-mail and any attachments are confidential and may be protected >>by legal privilege. If you are not the intended recipient, be aware >>that any disclosure, copying, distribution or use of this e-mail or >>any attachment is prohibited. If you have received this e-mail in >>error, please notify us immediately by returning it to the sender and >>delete this copy from your system. Thank you for your cooperation. >> >> >> > Comments embedded... >> >> > At 04:27 PM 3/22/2006 -0500, Benoit Bezaire wrote: >> >>======================== CL-c1 ======================== >> >> >> >>requirements >> >> >> >>contradiction between two paragraphs >> >>http://www.oasis-open.org/committees/download.php/14243/WebCGM_20_Requir >> ements.html#Internatio >> >> >> >>[[[ >> >>The use of Unicode with both graphical and non-graphical text strings >> >>was allowed in WebCGM 1.0. This reqirement continues for WebCGM 2.0. >> >>There were minor errors in the specification of the sequence tail for >> >>the complete code for UTF-8 and UTF-16. This is to be corrected in >> >>WebCGM 2.0. >> >>... >> >>The internationalization of links described by RFC3987 (IRI) was >> >>discussed by the user constinuencies of WebCGM. It was determined that >> >>there is no immediate requirement for fully internationalized links >> >>per IRI. The two major constinuencies (Air Transport Association, and >> >>AeroSpace & Defence) of WebCGM apply the specification to technical >> >>illustrating. Neither of those presently allow international character >> >>sets in their linking mechanisms. Full internationalization of WebCGM, >> >>specifically including IRI, can be deferred to a future version of >> >>WebCGM (e.g., a follow-on version 2.1), and should be deferred to >> >>avoid impact the high-priority schedule requirement. >> >>]]] >> >> >> >>So on the one hand, characters outside ASCII can be used in the CGM >> >>and on the other hand, elements with names outside ASCII cannot be >> >>linked to. internationalisation is needed for object names, for search >> >>strings, etc. Linking may be from WebCGM to non-WebCGM. Generality is >> >>needed. >> >> >> >>Yet the WebCFM 2.0 submission references RFC 3987, so such linking would >> >>be possible. >> >> >> >>***LH Preliminary Assessment*** >> >> >> >>This one confuses me a little. I suspect that CL may have misread the >> >>intent. IMO, the intent here was to support "reasonable" i18n in >> >>object names and links, but not to support such things as 'bidi' >> >>(string that are composed of unicode characters from different >> >>direction languages, e.g., some english chars (L2R), then some arabic >> >>(R2L), then some english, all in the same object id. >> >> >> >>The first quoted paragraph is correct -- utf8 & utf16 are allowed >> >>anywhere that S and SF data are allowed (if properly declared etc). >> >>The second paragraph was an attempt to avoid getting tangled up in >> >>URI/IRI/CharMod issues that are beyond the requirements of the 2.0 >> >>constituency, but that could take a long time to resolve. (Are there >> >>any such? Like bidi?) I believe that the flexibility in names is >> >>there. But ... is there any implication that we must support bidi in >> >>names, etc? >> >> >> >>Conclusion. We do support internationalized SF (even in id), as well >> >>as S, but I'm unsure about the implications of some of the more >> >>complicated unicode questions. Some research would help. >> >> >> >>***BB: opinion*** >> >>Does graphical and non-graphical text strings encapsulates hyperlink >> >>strings? >> >> > Yes, at least in metafile content "hyperlink strings" are type SF >> > (non-graphical text). >> >> > I guess there could also be a question about "hyperlink strings" in >> > hyperlinks coming from non-CGM content. Rereading 3.1.1.1 through 3.1.1.4, >> > it does not clearly state that this stuff applies to URIs (esp. fragments) >> > that are contained within CGM content, and equally to fragments that are >> > attached to URIs in non-CGM content, that address CGM content. >> >> > I think it is strongly implied, and everyone has implemented it thusly, but >> > it might be a small side issue to clarify it. (However, I don't think that >> > is the issue CL raises, or that you're asking about.) >> >> >>If yes, we do have a contradiction as it seems that the first >> >>paragraph states we support Unicode but the second states otherwise as >> >>we have decided not to use IRI. If hyperlink strings are not >> >>considered to be graphical and non-graphical text strings; then CL >> >>misunderstood. >> >> > My opinion -- I think that the intent of the 2nd paragraph is not clearly >> > stated (mea culpa, I guess). It is my recollection that our intent was >> > something like: continue the Unicode permissibility and specification of >> > 1.0; but don't get bogged down in *advanced* i18n issues (like, "can you >> > have bidi text in an objid? If yes, must all conforming viewers do it?") >> >> > Btw, recall some history -- the Unicode requirement came not from the >> > WebCGM user base (ATA, ASD, CALS, etc), but straight from the general, >> > CL-written, "Scalable Vector Graphics Requirements" of the late >> > 1990s. WebCGM 1.0 was a fusion of some of those general requirements and >> > technology-specific ones. >> >> > Summary. I think the 2nd paragraph was an attempt to defend against having >> > to spend a lot of time nailing down some very detailed and arcane i18n >> > requirements, because they are not primary, high-priority requirements of >> > the immediate 2.0 constituency (IMO, "whatever was specified in 1.0 is fine >> > for 2.0"). It was awkwardly and probably inaccurately expressed in "2.0 >> > Requirements" because we (collectively) don't have a lot of expertise on >> > i18n topics (yet). >> >> > Thoughts? What, if anything, should we do about it? >> >> > -Lofton. -- Regards, Benoit mailto:benoit@itedo.com This e-mail and any attachments are confidential and may be protected by legal privilege. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system. Thank you for your cooperation.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]