Issue CL-c2: Can a WebCGM 2.0 picture link to a multi-picture

[Benoit Bezaire <benoit@itedo.com>]

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

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. We can't
have a EBNF that allows it and wording that says otherwise.

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

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