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: Re: [cgmo-webcgm] Chapter 3 review


Thanks, Benoit, for the excellent review of Chapter 3.  (To them I have 
added your today's suggestion of a local TOC at start of Ch.3).

Processing Question.
-----
I can't try to go into them all right now, but I have a question for Dave 
and the group.  How do we plan to process the CD comments?  Dave, 
presumably, needs to keep inventory of all mail messages with all issues 
and comments, and ensure that we properly resolve them all.

The reason I ask:  I have been working on writing test cases, and I have 
found several problems and issues in Ch.5.  Even though I don't have a 
review assignment (for Ch.5), I will be sending these to the TC list.  As 
more people write their test cases, and more vendors progress their 
implementation work, I think that the issues list is going to grow 
considerably.

So ... are we going to try to resolve them all by email (hasn't been 
effective/efficient so far)?  By telecon (once per month won't do it, I 
don't think)?  A summer f2f (none planned yet)?

A Couple Key Issues.
-----
Two issues of Benoit (below attached) have been on my mind as well:

1.) will we need to replace URI with newer (internationalized) IRI?  (It 
might be required if this work is to become a W3C Rec, but I haven't 
started to think how IRI vs. URI relates to our targeted application 
constituency.)

2.) should we reference XML 1.1 instead of XML 1.0 Third Edition (the 
latter being latest errata release of XML 1.0)?  (I don't know the 
differences, but there was some interesting talk at W3C Technical Plenary 
in March, about how not very many people are migrating from 1.0 to 1.1.)

Regards,
Lofton.

At 04:34 PM 4/21/2005 -0400, Benoit Bezaire wrote:

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