RE: [cgmo-webcgm] ISSUE: should DOM have an executeFragment() method?

[Lofton Henderson <lofton@rockynet.com>]

Dieter,

Yes, I looked at the 'src' parameter on WebCGMMetafile.  But I hadn't yet 
given any thought to whether there were implications by it being on that 
interface as opposed to another.

Basically, I have no strong preference whether or not there is 
functionality equivalent to "executeFragment()" -- I only volunteered to 
start a discussion thread.  If the 'src' on WebCGMMetafile satisfies the 
proponents, then the question is closed.

Stuart, comments?  (I recall you expressing interest in the capability.)

-Lofton.


At 08:23 AM 1/25/2008 -0500, Weidenbrueck, Dieter wrote:
>Lofton,
>
>we have already a way of executing a fragment.
>The src parameter of the WebCGMMetafile Interface can take a fragment
>and execute it.
>If the base URL is omitted, and only a fragment is supplied, the
>fragment gets applied to the currently open document.
>
>Dieter
>
>-----Original Message-----
>From: Lofton Henderson [mailto:lofton@rockynet.com]
>Sent: Mittwoch, 23. Januar 2008 14:36
>To: cgmo-webcgm@lists.oasis-open.org
>Subject: [cgmo-webcgm] ISSUE: should DOM have an executeFragment()
>method?
>
>[This issue arose during today's telecon, while talking about pan/zoom.
>I took the AI to briefly encapsulated and start a discussion.  Without a
>recommendation...]
>
>ISSUE:  Should WebCGM 2.1 DOM have a method to execute the navigation
>specifications of a WebCGM URI fragment?
>
>DISCUSSION:  While discussing the form of the new zoom/pan DOM
>functionality, the telecon identified that there are several bits in
>WebCGM 2.0, and projected additions for WebCGM 2.1, that are related to
>the view within a picture.  These include:
>
>1.) The fragment syntax of chapter 3, and particularly the object
>behaviors of 3.2.1.4;
>2.) The viewcontext ApsAttr that is used in conjunction with #1;
>3.) The (deprecated) viewport <param> and the VDC-extent-fitting
><param>s of 3.4;
>4.) The user pan/zoom that viewers are required to offer by 3.2.1.5;
>5.) The projected getObjectExtents and pan/zoom methods of WebCGM 2.1;
>
>[1]
>http://docs.oasis-open.org/webcgm/v2.0/OS/webcgm-v2.0-index.html#webcgm_
>3_1_2_4
>[2]
>http://docs.oasis-open.org/webcgm/v2.0/OS/webcgm-v2.0-index.html#webcgm_
>3_1_2_5
>
>The WebCGM 2.1 spec needs to look at all of these and sort them out --
>priorities and interactions.  For example, we discussed and concluded
>that there is potential conflict between #4 and #5, but that user should
>be warned against doing ill-defined things (e.g., executing #4 user
>pan-zoom while a script is modifying the view #5 is a bad idea, and that
>the result is not standardized.)
>
>Also for example, there was some thought of further deprecating the
><param>s -- though they might fill some important niche in HTML
>integration, on the other hand it is unclear whether anyone has
>implemented them (a confidential survey is pending).
>
>"Cleaning house" aside, a substantive question was identified.  While #2
>allows to set the 'viewcontext' attribute on an object, that setting is
>only realized if a link to that object is executed.  I.e., only by
>executing a 'linkuri'.  And the pre-packaged behaviors of #1 are only
>available by executing a linkuri to an object.
>
>We discussed that the capabilities of #1 and #2 could be simulated in
>script by a sequence of steps using getObjectExtents and pan/zoom.
>
>The question arose:  why not have, in addition to DOM pan/zoom method, a
>convenience method that enables execution of WebCGM fragments that
>address an object (by apsid) or objects (by name) and apply the dozen
>pre-packaged object behaviors of 3.2.1.4?
>
>Some thought it would be handy.  There was not much discussion of the
>implementation burden, nor was there careful development of the use
>cases and requirements.
>
>OPTIONS:
>1.) YES, add such an executeFragment() method in addition to the new
>pan/zoom;
>2.) NO, just add the capabilities of the new getObjectExtents and
>pan/zoom;
>
>RECOMMENDATION:  None yet.
>#####
>
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in
>OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php