RE: [cgmo-webcgm] CL-c2 closure

["Cruikshank, David W" <david.w.cruikshank@boeing.com>]

 I agree with the proposal and endorse the recommendation of the wording
in b-3 (deprecation language)

Dave


Technical Fellow - Graphics/Digital Data Interchange
Boeing Commercial Airplane
206.544.3560, fax 206.662.3734  <-- NEW NUMBERS
david.w.cruikshank@boeing.com

-----Original Message-----
From: Lofton Henderson [mailto:lofton@rockynet.com] 
Sent: Friday, April 14, 2006 10:11 AM
To: cgmo-webcgm@lists.oasis-open.org
Subject: [cgmo-webcgm] CL-c2 closure

[0]
http://www.oasis-open.org/committees/download.php/17342/CL-comments.html
#CL-c2

INTRODUCTION.  CL-c2 [0] and related (c7, d10) dealt with the change to
single-picture in WebCGM 2.0.  Specifically, to changes in the fragment
that limit pictseqno to 1.  In the thread starting at [1], we agreed
that this was a mistake and no one noticed it before CL -- it was our
intent to limit number of pictures to 1 in WebCGM 2.0 instances, but
there are all sorts of legacy questions about fragments coming from
non-CGM sources (e.g., HTML), etc.  The final conclusion is that we
should remove the "pictseqno ::= 1" line, and restore to 3.1.2.1 the
WebCGM 1.0 rules for what to do with an out-of-range pictseqno.

[1]
http://lists.oasis-open.org/archives/cgmo-webcgm/200603/msg00048.html

QUESTION.  Does that solution answer the three CL questions (a, b, c) at
[0]?  Not clearly, in my opinion.

>     *  a.) What does a 2.0 viewer do with an external pseq=2 frag/link

> into a 2.0 file?
>     * b.) What happens with a 2.0 viewer handling a 1.0 file 
> containing a
> pseq=2 frag/link?
>     * c.) Can a 2.0 file have a pseq=2 fragment pointing to a 1.0
file?

PROPOSAL.

a.) The 3.1.2.1 rule from 1.0, which we are going to restore to 2.0,
says, "If the picture sequence value exceeds the number of pictures in
the metafile, the last picture is displayed."  So our solution answers
this question.
c.) According to our proposed solution, this is specified -- we are
removing the "pictseqno=1" restriction from the fragment, and 1.0 files
could have multiple pictures.  What the 2.0 viewer actually *does*
should be answered consistently with #b...
b.)  Unclear from our solution.  I see three choices:
b-1.) must support (show 2nd picture);
b-2.) must show picture 1;
b-3.) invoke similar language to what we have used to define deprecation
(7.2.2):  "...must be supported by conforming 2.0 viewers that support
conforming 1.0 content."

I recommend b-3.  But I don't really care strongly.  There really isn't
any multi-picture 1.0 content, so the question is academic, right?

-Lofton.