[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Chapter 3 review
Here is my review of Chapter 3... 3.1.1.1 Fragment definition - Should we change URI references to IRI references? (see: http://www.ietf.org/rfc/rfc3987.txt) (for the entire spec) - Should we update the XPointer reference (that specification has been superceded)? 3.1.1.2 Fragment EBNF - Could we add this before the webcgmfragment ::= The following notation is used: * *: 0 or more * +: 1 or more * ?: 0 or 1 * (): grouping * |: separates alternatives * double quotes surround literals 3.1.1.3 Fragment Character Repertoire - Should we update our XML 1.0 (second edition) to the third edition or go to XML 1.1 (Rec) - Should we update our HTML 4.0 reference to 4.01 or XHTML? 3.1.2.4 Object behaviors - Adding an introduction might be a good idea. 3.1.2.4.1 Enumeration of behaviors - A brief explanation about the table could be useful. 3.1.2.4.2 Definition of target rectangle - I have a question regarding the fourth bullet... I'm assuming that the target rectangle of the individual objects is calculated "for each objects" according to the three rules found above, is that correct? Could the wording make that a bit more clear? 3.1.2.4.3 Definition of behaviors - The only case where 'zoom' and 'move' behave differently is if the target rectangle is smaller than the viewer's viewport; is it worth two keywords? - When we say: The resulting view is a full-picture view, not a zoomed view... Do we zoom out even if the target rectangle already fits in the viewer's viewport? - highlight_zoom, highlight_move, highlight_zoom_all, highlight_move_all are all too brief (in my opinion). Ex: highlight_zoom -- Same as the combined effects of zoom and highlight. 'combined effects' implies for the reader to imagine a few things and may result in different interpretations. I'm quite sure I understand the intent, but there's probably a clearer way of specifying this. The problem is that the definition of 'zoom' and 'highlight' contradict themselves regarding zooming in (one zooms in, the other doesn't); so what happens when you 'combined the effects'? highlight_zoom should probably be wording as such: Same as the zoom, and additionally highlights the first object selected while ignoring the 'viewcontext' attribute if present. 3.1.3.4 Example 3 - Should be removed since it is deprecated functionality. - If example 3 is removed, update wording in Example 4. 3.1.3.6 Example 5 - The explanation is out of date. 'zoom' is now the default behavior, thus no highlighting should happen. 3.1.3.7 Example 6 - The explanation is out of date. 'zoom' is now the default behavior, thus no highlighting should happen. 3.1.3.8 Example 7 - The explanation is out of date. 'zoom' is now the default behavior, thus no highlighting should happen. 3.2.1 Application structures - We should add, The following notation is used: * *: 0 or more * +: 1 or more * ?: 0 or 1 * (): grouping * |: separates alternatives * double quotes surround literals 3.2.1.1 Grobject - I find the bullet 2, 3, 4 to be irrelevant. They don't provide an explanation for determining the "pick" priority. "pick" should also be indepedant of 'linkuri'. 3.2.1.2 Layer - Add grnode to the first sentence. 3.2.1.5 Grnode - Fix Description to (minor errors): The application structure 'grnode' is meant to group basic graphical primitives only. For this reason, 'grnode' must contain the APS 'id' parameter required by CGM:1999 for all APS. 'id' is the only APS attribute allowed on a 'grnode'. The content of a 'grnode' is the same as for the 'grobject' Application Structure. Even if 'visibility' and 'interactivity' are not allowed on the APS, the 'grnode' supports inheritance (i.e., it is possible to make a 'grnode' visible or non-visible by inserting it within an object which support the 'visibility' attribute). - Fix Viewer Behavior to (minor errors): Unlike other application structures, 'grnode' is not interactive; i.e., it does not receive mouse events. The content of a 'grnode' can however be interactive if it is a direct child of a 'grobject', 'para' or 'subpara'. Additionally, if a mouse event is triggered on the geometry of a 'grnode', an ancestor node, if of type 'grobject', 'para' and 'subpara', instead responds to the event. See the Event interface for more information regarding mouse events. 3.2.2.6 Screentip - Why is a screentip not inherited? 3.2.2.9 Visibility - The visibility is inherited by ALL APS, not only the ones listed (missing grnode in the sentence). - Initial value should be 'inherit' (assuming proposal is accepted). 3.2.2.10 Interactivity - The interactivity is inherited by ALL APS, not only the ones listed (missing grnode in the sentence). - Initial value should be 'inherit' (assuming proposal is accepted). 3.4 WebCGM and the OBJECT tag - This section should be re-written to be xhtml friendly, ex: <OBJECT DATA="xxx.cgm" TYPE="image/cgm;Version=4;ProfileId=WebCGM"; WIDTH=200; HEIGHT=100> should be: <object data="xxx.cgm" type="image/cgm;Version=4;ProfileId=WebCGM" width="200" height="100"> etc... - The event-related attributes, ONCLICK,...,ONMOUSEOVER, are permitted but their effect is undefined in this version of WebCGM. Mouse-related events occurring within the area of the WebCGM picture will be handled by the WebCGM viewer, which need not expose these events. ??? THIS HAS TO BE REVISED! WOULD THIS BE A WAY TO WORK AROUND OUR addEventListener PROBLEM?! ??? -- Benoit mailto:benoit@itedo.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]