OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmopen-members message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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