OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[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]