[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: WebCGM preview
Lofton, please find attached a Word file with the tables. I applied small changes and added some comments. Dieter ----- Original Message ----- From: "Lofton Henderson" <lofton@rockynet.com> To: "Dieter" <dieter@itedo.com>; <cgmopen-members@lists.oasis-open.org> Sent: Wednesday, May 30, 2001 9:59 PM Subject: Re: WebCGM preview > Dieter, > > Preliminary request #1: could you please redo your first table so that it > reflects the current Second Release text? You continue to send versions > that reflect the original 1/99 text. The current 2nd release text > represents what we have discussed and agreed since initial publication, and > I consider that it is the only defensible basis for discussing further change. > > Preliminary request #2: would it be possible to send your two html tables > as attachments instead of embedded (or in addition to embedded)? In that > way, we could edit comments into the table for discussion. The embedded > tables also cause some difficulties for my mailer (I can read them, but > they flatten upon "reply", etc). > > I'll make a couple of comments, and will refer to your table by row (1-4) > and column (1-4). > > But ... I think that this is getting to the point where we cannot resolve > it by email. I think a conference call is going to be required. I won't > be able to do such until next week (mid-late week) at earliest. > > At 08:14 PM 5/30/01 +0200, Dieter Weidenbrueck wrote: > >[...] > >I hate to come up with major changes at this point, it just shows that I > >should have thought about it earlier. So here is another table proposing > >the minimal changes that make sense. > > I am apparently missing something. I don't understand your claim "minimal > changes that make sense". > > R1/C1: I don't have a problem with your recommendation. I think it was > intended, but an oversight. It is sensible, what one would expect, and > doesn't contradict anything else. > > R2/C1: The spec already says this, but not precisely. It doesn't say > "highlight", it says "indicate visually...". The intention is plain, but > it could be said better. > > R4/C1: The current (2nd rel) spec specifically says "no zoom", contrary to > your Table 1. > > R3/C1: For consistency with previous, we recently generated a "no zoom" > editing directive for this case (the region replaces the geometry for > picking purposes -- i.e., object identification purposes -- it is not in my > view a surrogate view context) > > >We definitely need to apply changes to make 3.2.1.1. and 3.1.2.4. > >consistent, one way or the other. > > You're losing me here. > > I don't see how your new "zoom" prescription of R3/C1, R3/C2, R4/C1, and > R4/C2 are required for "consistency". I see no contradiction if they > remain "no zoom", as they currently are, and as has been discussed and > decided. Perhaps I'm missing some statement. Can you point me to two > phrases that contradict each other in the current 2nd Release text? I.e., > something that can be implemented because it says "do A" in one place and > "do B" in another place? > > > > >As far as IsoView is concerned I can still change the implementation to > >whatever comes out of this discussion. I can go either way without > >problem. However, I see Harry's good comments, and I know that some of the > >current definitions will at least disappoint users. > > > > My preliminary survey of implementators: > > 3 do no-zoom on the questionable cases; > 1 does zoom; > 1 hasn't responded yet; > (also I asked Greg at micrografx -- no response yet). > > Regards, > -Lofton. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC