[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re[3]: [cgmo-webcgm] Issue CL-c2: Can a WebCGM 2.0 picture link to a multi-picture
Hi Lofton, We did decide not to change the EBNF. I don't feel like searching all the minutes for that resolution though. It was agreed upon so that _most_ 1.0 files could be handled easily by a 2.0 viewer. I personally have no objections for removing the picseqno=1 restriction to make this problem go away. Others have to express their opinion though. -- 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. Thursday, March 23, 2006, 7:12:50 PM, you wrote: > 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]