Re: [cgmo-webcgm] Issue: WebCGMPicture::highlight()

[Lofton Henderson <lofton@rockynet.com>]

All --

Following our telecon discussion, I think we agreed that we should have
an erratum with editorial clarification that explicitly states the
correspondence -- hightlight('new') DOM call corresponds to
'newHighlight' fragment keyword, and highlight('add') corresponds to
'addHighlight'.  

Barring any objections, I'll add this to our errata collection. 
(Which I will format properly and process per OASIS 
procedures.)

-Lofton.

At 07:58 AM 3/31/2010 -0600, Lofton Henderson wrote:
> Thanks Benoit.  I agree that
> the wording of the highlight() method is confusing, and could use
> clarification.  Addressing your questions at the end of your
> message...
>
> 1.) You asked, "What do add and new map to?"  I believe
> that the editor's careless use of "corresponding...keywords"
> intended this correspondence:
> -- highlight('add') corresponds to keyword 'addHighlight'
> -- highlight('new') corresponds to keyword 'newHighlight'
> To my way of thinking, those are the choices that make the most sense for
> "corresponding".  (All the same syllables in each
> one.)
>
> 2.) It is my belief that 'add' and 'new' arguments to hightlight() do NOT
> cause any navigation.  And it should definitely not be viewer
> dependent.  I say "no navigation", because one driving
> motivation for the 2.0 redefinition of object behaviors was to unbundle
> navigation from highlighting, and it would have been somewhat
> inconsistent to bundle navigation in with the simple keywords 'add' and
> 'new'.
>
> 3.) Yes, we goofed with "corresponding keywords".  See #1
> for my view of what was intended.
>
> 4.) We should clarify so that users get the same result (no navigation,
> or navigation).  I don't think the point about "default"
> is decisive here.  
>
> This question, btw, was raised in January 2009,
> http://lists.w3.org/Archives/Public/public-webcgm-wg/2009Jan/0027.html
> I don't see a definitive resolution in that thread, but I believe the
> agreement was as I advocated in #1.  (We may have resolved it in
> teleconference.)
>
> Finally... The 2.0 test suite [1] contains a test,
> "Picture-highlight".  The status matrix [2] lists two
> "pass":  Larson and PTC.  Both implementations
> execute the test without any zooming or other navigation, and the test
> description itself does not mention any navigation.  I would be very
> reluctant to support a clarification that is at odds with those
> implementations and the 2-pass test results that were based on
> them.
>
> Thoughts?  (Anyone.)
>
> -Lofton.
>
> [1]
> http://docs.oasis-open.org/webcgm/test-materials/webcgm20ts/webcgm20-ts-index.html
> [2]
> http://docs.oasis-open.org/webcgm/test-materials/matrix.html
>
> At 08:09 AM 3/30/2010 -0400, Bezaire, Benoit wrote:
>
> > Hi All,
> >  
> > This is mostly a WebCGM 2.0 issue, but it also applies to 2.1 also. The
> > WebCGM 2.0 and WebCGM 2.1 PR spec says the following about the highlight
> > method:
> >  
> > highlight
> >
> > Highlights a collection of Application Structures (APSs). WebCGM also
> > allows for highlighting of APSs using the
> > IRI
> > fragment syntax. The exact method of highlighting is viewer
> > dependent. The highlight method provides a way for WebCGM script writers
> > to highlight APSs in the same way a IRI fragment would. It also allows
> > for highlighting of entire layers. Highlighting is not defined for
> > WebCGMPicture nodes or XML Metadata nodes. APS of type
> > 'grnode'
> > are not valid in the node list, and shall cause no change to the viewed
> > image or the DOM tree. See the
> > 'visibility'
> > APS Attribute for discussion of its effect on execution of the
> > highlight method. 
> >  
> > Parameters
> >
> >
> > nodes of type WebCGMNodeList
> > A WebCGMNodeList of APP_STRUCTURE_NODEs to highlight.
> >
> > type of type WebCGMString
> > Denotes a behavior identical to the corresponding
> > highlighting
> > object behavior keywords of the fragment syntax. Values: { add | new
> > }.
> >
> > Return value
> > No return value.
> >
> > Exceptions
> > No exceptions.
> >
> >
> > More specifically about the type attribute. The spec says behavior
> > identical to the corresponding highlighting object behavior keywords of
> > the fragment syntax. Values: add | new.
> >
> > Now jumping to the fragment syntax, we notice that add and new or not in
> > the list. Instead we have:
> >
> > full 
> > zoom
> > move
> > newHighlight
> > addHighlight
> > full+newHighlight
> > zoom+newHighlight (default)
> > move+newHighlight
> > full+addHighlight
> > zoom+addHighlight
> > move+addHighlight
> > clearHighlight
> >
> > Questions:
> >
> > -          What do add and
> > new map to?
> > -          Should the
> > highlight() method do any navigation (zoom, full, move)? Is that up to
> > the implementation?
> > -          I don t think we
> > can say identical to the corresponding [&] keywords , there is no
> > corresponding keywords?
> > -          What should be
> > done if a user is expecting navigation (say zoom); and another doesn t
> > want the zooming. After all, one could argue that zooming should be
> > included since that s WebCGM 2.0 default and there is no zooming API in
> > the WebCGM 2.0 specification.
> >
> > Regards,
> > Benoit