OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[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]