RE: re[2]: invalid/extreme rectangles in setView()

Benoit, Stuart --

At 08:23 AM 12/12/2008 -0800, Galt, Stuart A wrote:

>My sense of what was said in the telecon was slightly different
>
>TRUE gets returned if the viewer changed the view and FALSE gets
>returned if
>the viewer did not set the view.  In theory the viewer could return
>FALSE even
>though you passed it a valid rectangle but it was feeling ornery that
>day and didn't want to change the view...

That sounds familiar.  But unfortunately I didn't record the precise 
definition.  Since you are the keeper of the Minutes, I guess we should go 
with your recollection.

Benoit?

-Lofton.

> > -----Original Message-----
> > From: Lofton Henderson [mailto:lofton@rockynet.com]
> > Sent: Friday, December 12, 2008 8:04 AM
> > To: WebCGM WG
> > Subject: RE: re[2]: invalid/extreme rectangles in setView()
> >
> >
> > In the telecon and email, we agreed with Benoit's proposal
> > for Option 1; his proposed wording on this part of the
> > setView() issue was:
> >
> > "i) boolean: TRUE if new view was set; FALSE if rectangle was
> > invalid."
> >
> > Is that the wording that we should use?  (Benoit, as the
> > proposer, is this the wording thatyou want?)
> >
> > [We had some discussion in the telecon about it:  some sense
> > the TRUE and FALSE do not apply to the same condition/test.]
> >
> > Per the telecon, I am putting the above into the DoC unless
> > there is some quick substitute wording.  (It may be reopened
> > later, in the next cycle.)
> >
> > -Lofton.
> >
> > At 03:57 PM 12/4/2008 -0500, Bezaire, Benoit wrote:
> >
> > >Let's try an make is easy for script writers, ok? Else these new DOM
> > >calls will never get used.
> > >
> > >Two opposite corner points just complicates the code for script
> > >writers, they have to add 'checks' to determine which point
> > is which. I
> > >didn't oppose the decision for viewcontext back in WebCGM 2.0 since
> > >script writers were unlikely to change the viewcontext. I think it's
> > >different for WebCGMRect() though.
> > >
> > >Benoit.
> > >
> > >-----Original Message-----
> > >From: public-webcgm-wg-request@w3.org
> > >[mailto:public-webcgm-wg-request@w3.org] On Behalf Of Don
> > >Sent: Thursday, December 04, 2008 3:30 PM
> > >To: Lofton Henderson; WebCGM WG
> > >Subject: re[2]: invalid/extreme rectangles in setView()
> > >
> > >
> > >Lofton,
> > >
> > >  >  At 01:12 PM 12/4/2008 -0600, Don wrote:
> > >
> > >  >  >Lofton,
> > >  >  >
> > >  >  >  >  All --
> > >  >  >
> > >  >  >  >  This is a dangling open piece of Benoit's
> > setView() questions.
> > >We closed  >  >  >  the other piece (about different aspect
> > ratios).  I
> > >can't find any thread  >  >  >  discussion about this piece, after
> > >Benoit's message below (top), and  >  >  >  it apparently
> > remains open.
> > >  >  >
> > >  >  >  >  Discussion?
> > >  >  >
> > >  >  >I believe we should have very basic checking for Invalid
> > >rectangle and  >  >return boolean as Benoit suggested. A minimal
> > >invalidity check would be  >  >if ymax < ymin or xmax < ymin.
> > >
> > >  >  Side question:  I just looked at WebCGMRect.  Does
> > anyone recall
> > >why we  >  parameterized it in terms of "lower left corner"
> > and "upper
> > >right
> > > >  corner"?  Why not just "two diagonally opposite corner points P1
> > > > and
> > >P2  >  [(x1,y1) and (x2,y2)]"?
> > >
> > >I not sure why but I think it would be nice to be consistent with
> > >viewcontext where we define viewcontext as "defining two
> > corner points
> > >of a rectangle".
> > >
> > >http://www.w3.org/TR/2008/WD-webcgm21-20080917/WebCGM21-IC.ht
>ml#webcgm_
> > >3
> > >_2_2_2
> > >
> > >  >  For the former, it sets up an error condition (or is
> > "error prone").
> > >Do we  >  need that error condition?  For the latter, the only error
> > >condition is a  >  degenerate rectangle, i.e., zero area, i.e.,
> > >xmin=xmax and/or ymin=ymax.
> > >
> > >I don't think we need any error checking at all on WebCGMRect. A
> > >programmer may want to set a WebCGMRect = 0,0,0,0 for
> > example as some
> > >kind of indication.
> > >
> > >Don.
> > >  >  There may be a reason we did it this way (more error prone, or
> > >allows  >  setting an error), but I don't recall it.  I do
> > recall the
> > >stuff about  >  getObjExt() on an APS with no primitives, but we now
> > >return 'null' for  >  that, so we don't need the somewhat hokey
> > >mirrored rectangle.
> > >
> > >  >
> > >http://www.w3.org/TR/2008/WD-webcgm21-20080917/WebCGM21-DOM.h
>tml#webcgm
> > >r
> > >ect
> > >
> > >  >  -Lofton.
> > >
> > >
> > >  >  >  >  -Lofton.
> > >  >  >
> > >  >  >  >  At 09:44 AM 11/19/2008 -0500, Bezaire, Benoit wrote:
> > >  >  >  >  I remember this thread. I don't want to reopen old issues.
> > >  >  >  >
> > >  >  >  >  However, for this particular API, a script writer
> > can easily
> > >loose the  >  >  >  display (zooming on a very small rectangle or
> > >zooming our far enough that  >  >  >  nothing is displayed). I think
> > >the API should at least return a more  >  >  >  meaningful  value.
> > >  >  >  >
> > >  >  >  >  Some options:
> > >  >  >  >  i) boolean: TRUE if new view was set; FALSE is
> > rectangle was
> > >invalid.
> > >  >  >  >  ii) float: returns the scale factor between the
> > old view and
> > >the new view.
> > >  >  >  >  > 0 is successful, failed otherwise.
> > >  >  >  >  iii) WebCGMRect: a rectangle defining the old view.
> > >  >  >  >
> > >  >  >  >  Any of those would help the script writer understand what
> > >went wrong,  >  >  >  instead of getting in touch with
> > technical support.
> > >  >  >  >
> > >  >  >  >  Benoit.
> > >  >  >
> > >  >  >  >  From: Lofton Henderson
> > [mailto:lofton@rockynet.com]  >  >  >
> > >Sent: Tuesday, November 18, 2008 7:08 PM  >  >  >  To:
> > Bezaire, Benoit;
> > >WebCGM WG  >  >  >  Subject: Re: Question about setView()  >
> >  >  >  >
> > >>
> > > >  At 08:57 AM 11/18/2008 -0500, Bezaire, Benoit wrote:
> > >  >  >  >  I'm wondering if the wording of setView() is not
> > a bit short?
> > >The draft  >  >  >  doesn't say anything about invalid
> > rectangles being
> > >passed in for example.
> > >  >  >  >
> > >  >  >  >  Should more feedback be sent to the user? Currently, the
> > >function  >  >  >  prototype has a void return type. Should
> > we change
> > >that to a boolean or  >  >  >  something else? or throw an exception
> > >perhaps.
> > >  >  >  >  Dieter raised and we discussed a similar question a few
> > >months back.
> > >As a
> > >  >  >  >  general rule, CGM and WebCGM say what happens with valid
> > >input but have  >  >  >  been relatively silent about error
> > fallbacks,
> > >viewer error reactions, etc.
> > >  >  >  >  What we have done most recently is say something like
> > >"...has no effect".
> > >  >  >  >  We generally have not gone to more extensive
> > error reactions.
> > >See for  >  >  >  example the 'grnode' stuff that we added to the
> > >interfaces.
> > >  >  >
> > >  >  >  >  My view is that, if we start opening the door to
> > saying what
> > >viewers do  >  >  >  for this and that bad input, where do we stop?
> > >Should we go back and  >  >  >  define mandatory error responses for
> > >all bad input?
> > >  >  >
> > >  >  >  >  Note that the profile (Ch.6) *does* talk a lot about
> > >"degeneracies".
> > >It
> > >  >  >  >  says what is the graphical effect of a degenerate
> > primitive,
> > >etc., and  >  >  >  this is what is *suggested* in CGM:1999
> > itself --
> > >WebCGM just makes  >  it  >  >  >  normative.  (But saysnothing more
> > >about what the viewer should do  >  when  >  >  >  encountering
> > >degeneracies. Silent?  Warning?  Task-bar "abnormality"
> > >  >  >  >  icon?)
> > >  >  >
> > >  >  >  >  I guess I favor "...invalid input has no effect, neither
> > >graphical nor to  >  >  >  the DOM tree."  Then leave it to the
> > >implementor, what else the viewer  >  >  >  might do in the way of
> > >error response to the user.
> > >  >  >  >
> > >  >  >  >  I also question the possibility of a major scale
> > change, ex:
> > >scaling  >  > in by  >  >  >  a factor of 100 (and loosing
> > sight of the
> > >overall picture). Should the  >  >  >  user be told that
> > such a change
> > >occurred?
> > >  >  >  >  I guess I view this as another choice for implementors.
> > >  >  >
> > >  >  >  >  I could also live with putting some valid limits on it.
> > >"Valid rectangles  >  >  >  shall not change the scale by more than
> > >...blah..."
> > >  >  >
> > >  >  >  >  -Lofton.
> >
> >
> >

Received on Friday, 12 December 2008 16:42:06 UTC