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: Re: [cgmo-webcgm] Issue CL-c1: requirements contradiction between two paragraphs


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_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?

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.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]