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

[Benoit Bezaire <benoit@itedo.com>]

See inline...

Wednesday, March 22, 2006, 8:55:40 PM, you wrote:

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

> [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?
I'm implying that if you want to say "no you can't link to those
files" you _will_ need such wording. In that case, you will have the
situation that the EBNF contradicts the wording.

> (Btw, are you saying that "wording" can't add further normative
> constraints to conformance requirements expressed in EBNF?)
More or less, yes. That would be bad in my opinion. EBNF is a form of
well defined logical rules. If the logic isn't strong enough to cover
all cases, we have a problem.

>>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"? 
I don't care here, I was only going for the approach which represented
the least amount of work.

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

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