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

[Lofton Henderson <lofton@rockynet.com>]

At 09:36 AM 3/23/2006 -0500, Benoit Bezaire wrote:
>Thursday, March 23, 2006, 1:51:40 AM, you wrote:
>
> > I agree with Benoit here.
>
> > We decided that we didn't want to change the EBNF at some point
> > do not invalidate old content.

Hmmm... can you clarify?  I am not sure I understand.

>Please note that certain forms of
> > the EBNF REQUIRE the full fragment picterm.objterm and disallow
> > one of the abbreviated forms. Hence there a lot of files out there
> > that have a picterm in them.

Right.


> > Secondly, we support the concept of cascading profiles. At any time,
> > a cascaded profile may introduce multiple pictures for whatever reason.
> > This is now covered by both the EBNF and the DOM.
>
> > So Chris' question broils down to
> > "What will happen if there is a fragment pointing to a non-existing
> > picture inside a WebCGM 1.0 or 2.0 file?"
> > A case for error handling IMO
>That's how I see it too. We probably need a section in the spec
>that talks about error handling and the processing of 1.0 file (Lofton
>also mentioned this in an earlier email).

[Aside.  If you notice, WebCGM in general *avoids* error processing.  It 
usually doesn't tell a viewer what to do with a bad metafile.  In an 
exception, 1.0, *did* say what to do if you get an out-of-range picseqno or 
non-existent picid -- map it to an existing picture.  That is still in 
3.1.2.1, but modified some because of the 1-pic rule on content.]

Yes, Chris asked that specific question.  Then, as Benoit pointed out, 
access to multi-pic legacy 1.0 files is allowed via id but not by 
picseqno.  I'm sure this is not by conscious design.  So I ask again, why 
not just get rid of the fragment restriction that picseqno=1, and restore 
the missing picseqno mapping rule to 3.1.2.1?  2.0 metafiles can still have 
only one picture, and this solves the questions a-c that I raised as 
underspecified.

-- external picseqno=2 link coming into a 2.0 metafile follows the 3.1.2.1 
rule (selects the last picture, i.e., the only picture).
-- intra-20-metafile picseqno=2 link to a legacy 1.0 metafile is 
allowed.  (And cascading is supported for multi-pic profiles)
-- etc.

So we can answer Chris's specific question, only.  Or we can make a couple 
of simple changes and straighten out his question and several related 
questions.


> > As a side note, if anybody opens (if he can find one)

There was one in the 1.0 Test Suite.  I did ask that question in my 
original assessment -- are there any real-world multi-pic metafiles (and 
assume the answer is "no", unless for example the petro application people 
are cascading multi-pic applications off of webcgm).  So the consequences 
of our decision, on legacy applications, are small.  So why not clean up 
the mess and go a little further than Chris's question, to the related 
underspecified questions?

-Lofton.

>a 1.0 file with
> > multiple pictures in it, it can not be saved this way as a 2.0 file.
>Yep.
>
>--
>  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.
>
> > So he has to hand-edit the file and separate the pictures into separate
> > files.
>
> > Regards,
> > Dieter
>
> >> -----Original Message-----
> >> From: Benoit Bezaire [mailto:benoit@itedo.com]
> >> Sent: Wednesday, March 22, 2006 11:16 PM
> >> To: cgmo-webcgm@lists.oasis-open.org
> >> Subject: [cgmo-webcgm] 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.