Re: [cgmo-webcgm] Issue CL-c2: Can a WebCGM 2.0 picture link to a multi-picture

[Lofton Henderson <lofton@rockynet.com>]

Hi Benoit,

Comments embedded...

At 05:16 PM 3/22/2006 -0500, Benoit Bezaire wrote:
>======================== CL-c2 ========================
>
>WebCGM alowed multiple pictues per file but warned against using it
>(deprecated in effect). WebCGM 2.0 requires that only a single picture
>is used.
>
>Can a WebCGM 2.0 picture link to a given picture in a multi-picture
>WebCGM 10 file?
>
>***LH Preliminary Assessment***
>
>This is a good point, that we should clarify. There is no problem with
>WebCGM 2.0 content rule of 1 picture per metafile. The problem arises
>with fragments: 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?
>
>Question. Other than test suite files (ATA, WebCGM), is anyone aware
>of any multi-pic files in practice? If the answer is "no", then to
>some extent it doesn't matter how we answer a-c. Since we don't
>specify error reactions of viewers, we could treat #a: map it to the
>1st picture (and inform user), which would match the 1.0 spec for an
>out of range picture number. Proposal for #c: "no", invalid data.
>Proposal for b: like #a. For #c, I would have been inclined to say
>"handle it as 1.0 viewer should handle it", if multi-pic metafiles
>were common. But ... it doesn't matter, if there are none.
>
>Note. This illustrates a general problem with changing 1.0 specs for
>2.0. We don't have a clear policy about how 2.0 viewers need to handle
>valid 1.0 content. Our deprecation policy (7.2.2) is slightly wooly,
>"Deprecated features must not be present in conforming 2.0 content,
>but must be supported by conforming 2.0 viewers that support
>conforming 1.0 content. This doesn't say whether 2.0 viewers must
>support 1.0 metafile content, or must support 1.0 constructs that come
>from non-CGM content.
>
>Conclusion. Probably can take "strict" approach, since no real-world
>impact. (It's like deleting an unimplemented feature at W3C CR stage
>of a new standard.) The general question of "2.0 viewer handling of
>valid 1.0 metafiles" probably deserves some more thought and
>discussion.
>
>***BB: opinion***
>My initial reaction to CL's question "Can a WebCGM 2.0 picture link to
>a given picture in a multi-picture WebCGM 1.0 file?" was: why not.

I can go either way.  More ...


>The WebCGM 2.0 Fragment EBNF still supports it (via picterm ::=
>pictureid | pictsequence, but note that picseqno ::= "1"). In my
>opinion, if we want to disallow linking to a given picture in a
>multi-picture WebCGM 1.0 file, we have to change the EBNF.

Ah, you're saying that it's allowed because only 'picseqno' is constrained, 
and 'picid' is not, at [1] (and at 3.1.2.1).  Okay, fair enough.

[1] http://www.w3.org/Submission/WebCGM20/WebCGM20-IC.html#webcgm_3_1_1

>We can't
>have a EBNF that allows it and wording that says otherwise.

I don't understand.  I don't see such wording.  What am I missing?

(Btw, are you saying that "wording" can't add further normative constraints 
to conformance requirements expressed in EBNF?)


>Why not reply?: Yes, please refer to the 'pictureid' term found in the
>Fragment EBNF.

Could do.

But, playing devil's advocate ... why would we want to allow multi-picture 
access via picid, but not via picseqno?  Why not just delete the line 
picseqno ::= "1"?  The 2.0 single-picture content rule still remains.  So 
let picseqno be 2, if a 2.0 file is referencing a multi-pic 1.0 legacy 
file.  If it's referencing a 2.0 file, then ... we could revert to the 
3.1.2.1 picseqno wording of 1.0 (if picseqno is "too big", display the last 
picture in the file).

I don't care very strongly about how we resolve this, because there don't 
seem to be many multi-pic files in practice.  (Houston, do we have a 
problem?  I.e., what do petro application people think about this?)

When we're done, I still think the reader should be able to answer about 
the three cases a, b, c expressed in CL-c2 analysis [2] (modified per 
Benoit's observation that the issue isn't limited to picseqno, but also 
involves picid.)

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

Note also that CL-c7 [3] and CL-d10 [4] are related.

[3] 
http://www.oasis-open.org/committees/download.php/17342/CL-comments.html#CL-c7
[4] 
http://www.oasis-open.org/committees/download.php/17342/CL-comments.html#CL-d10

Regards,
-Lofton.

p.s.  I'll be travelling and probably slow to respond for the next few days.