|Subject:||RE: [cgmo-webcgm] ISSUE: should DOM have an executeFragment() method?|
|From:||Weidenbrueck, Dieter (dwei...@ptc.com)|
|Date:||Jan 25, 2008 5:22:48 am|
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.
-----Original Message----- From: Lofton Henderson [mailto:lof...@rockynet.com] Sent: Mittwoch, 23. Januar 2008 14:36 To: cgmo...@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 188.8.131.52; 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 184.108.40.206; 5.) The projected getObjectExtents and pan/zoom methods of WebCGM 2.1;
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 220.127.116.11?
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