[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue CL-c1: requirements contradiction between two paragraphs
======================== CL-c1 ======================== requirements contradiction between two paragraphs http://www.oasis-open.org/committees/download.php/14243/WebCGM_20_Requirements.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? 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. -- 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]