[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue CL-c2: Can a WebCGM 2.0 picture link to a multi-picture
======================== 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]