Re[2]: [cgmo-webcgm] Issue CL-c1: requirements contradiction between two paragraphs

[Benoit Bezaire <benoit@itedo.com>]

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...

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