Re: [cgmo-webcgm] New draft snapshot

[Lofton Henderson <lofton@rockynet.com>]

Ben et al,

Here are a few initial comments.  I may send more later, but wanted
to get my action item (attached) circulated.

0.)  Substantive:
-----
I attach some initial wording for my action item about Coordinates. 
It should be clearer now.  Comments welcome.

1.)  Editorial:
-----
Exception DOMException:  check and fix the (non-) correspondence
between the IDL definition block and the following Constants' definition,
after the INVALID_ACCESS_ERR code.

2.)  Editorial:
-----
s/Returns the Metafile Descriptor/Returns the Metafile
Description/

3.)  Ed & substantive:
-----
(e.g., "ProfileId:WebCGM,ProfileEd:1.0,Source:A software
vendor,Date:20040602,ColourClass:monochrome") -- this is not a valid
clear text representation of a sample Metafile Description string. 
In the WebCGM instance, it must be a string of substrings, e.g.,
"'ProfileId:WebCGM''ProfileEd:1.0'
'Source:A software vendor''Date:20040602'
'ColourClass:monochrome'" 
That said, do you want the DOM interface to be the same, i.e., the
single string from the Metafile Description element (with the above
structure)?  Or do you want it to be a list of strings?

4.)  Substantive:
-----
setAttributeNS:  Why have this?  You said (below), 

> "- Added
> setAttributeNS().  We were able to set WebCGM attributes but
>   not the non-WebCGM one."  

What is an example usage scenario?  It would apparently be there for
adding private (application metadata) attributes to private (application
metadata) elements coming from XML Companion files.  Why?  In
sec 1.1.b we say, "The WebCGM DOM could almost be perceived as a
'readonly' DOM. It is true that some methods on interfaces allow users to
change an Application Structure style but, unlike the DOM Level 3
specification, it does not allow for removal or insertion of new Nodes
into the object model."  The changing of APS styles is a
transient effect for (graphical) viewing and interaction feedback. 
The changes can't (apparently) be serialized into a changed WebCGM
instance or changed XML Companion file -- this WDOM is not an
authoring/editing facility.  So ... I don't understand the use case
for this.

5.) Substantive:
-----
Appendix C, ECMAscript binding ("ITEDO to supply"):  we
should discuss the schedule for this.  We are telling vendors to
start implementing after tomorrow's telecon.  A binding is needed
soon.

Regards,
-Lofton.


At 01:49 PM 8/3/2004 -0400, Benoit Bezaire wrote:
> Hi all,
>
>   Attached you will find a new draft of the spec.  There are no
> green
>   boxes in this one, which is a good sign.
>
>   The changes are:
>   - Removed the Hyperlink interface.  I couldn't get
> Hyperlinks
>   working with the 'attributes' attribute of the Node interface
> since
>   Hyperlinks were not deriving from Node.  Instead, I propose
> that
>   Hyperlinks and 'name's be expressed using DOMStringList
> objects.
>
>   - Changed the datatype of the 'value' attribute on the Attr
>   interface from DOMString to DOMStringList since we have
> several
>   attributes in WebCGM that can take more than a single
> value.
>
>   - Changed setters/getters on the AppStructure interface to
> handle
>   DOMStringList.
>
>   - Added RemoveEventListener on the Picture interface.
>
>   - Removed linkuri specific APIs from DOM.
>
>   - 'src' attribute was moved from getWebCGMDocument interface to
> the
>   Metafile interface (this is closer to what other technologies are
> doing).
>
>   - Changed 'number' datatype to a 'float'.  Number was
>   underspecified.
>
>   - Changed 'integer' datatype to 'unsigned short'.  Integer
> was
>   underspecified.
>
>   - Modified wording for 'namespaceURI', 'prefix' and
> 'localName'.
>
>   - Added setAttributeNS().  We were able to set WebCGM
> attributes but
>   not the non-WebCGM one.
>
>   - 'intensity' is still intensity; here's why...  I tried to
> come up
>   with other names (whiteout, fadeout, lightness, etc...), but all
> of
>   them in my opinion were prone to be misinterpreted.
>   What I did do however, is to make the wording of the spec very
> clear
>   that this attribute makes colors whiter.  I've inserted the
> equation
>   and added an example to remove any misinterpretation of the
>   equation.  If this attribute name is unacceptable to some
> group
>   members I'll be happy to change it to something else once
> consensus
>   is reached in emails.
>
>   - Added 'pictid' to the Picture interface.  Itedo noticed
> that
>   pictid is used in linkuris but that they were currently no
> way
>   for accessing a pictid given a Picture object.  It is
> currently set
>   as a readonly attribute.
>
>   Please send comments regarding latest draft to the mailing
> list.
>
>   My next document will likely be one proposing a set of rules
> and
>   pseudocode for the applyCompanionFile method.
>
> -- 
>  Benoit                
> mailto:benoit@itedo.com

Title: WebCGM DOM

WebCGM Document Object Model (DOM) Specification

[...]

1. WebCGM Document Object Model

[...]

1.1.3 Coordinate values -- Normalized VDC (NVDC)

In a WebCGM instance, the representation of coordinates (VDC) is influenced by several CGM elements: VDC TYPE, VDC EXTENT, and SCALE MODE. WebCGM requires that SCALE MODE be 'metric', but places few other constraints. Therefore VDC (times some scale factor) are equivalent to millimeters, but otherwise the coordinate system could have a lot of variability: upper-left or lower-left origin, right-handed or left-handed, integer values or real values (floating or fixed), etc.

To simplify working with coordinates, the WebCGM DOM defines and uses a canonical, normalized coordinate system, Normalized VDC (NVDC).

NVDC units are millimeters, in a coordinate system whose origin corresponds to the lower left corner of the VDC extent, with the X axis pointing to the right, and the Y axis pointing up. The following examples illustrate the correspondence between NVDC and VDC values for several WebCGM instances.

Example 1: Simplest possible example, the VDC and the NVDC are identical

• VDC Type: Real
• VDC Extent (lower-left & upper-right corners): (0.,0.) (150.,100.)
• Scale Factor: 'metric', 1.0

The picture's VDC have lower-left origin, X increases to right, Y increases up, picture is 150 mm wide and 100 mm high. The NVDC are identical,: (0.,0.) for lower-left corner, (150.,100.) for upper-right corner. If (x,y) are VDC and (x',y') are NVDC, then:

• x' = x
• y' = y

Example 2: The VDC define an upper-left origin, and correspond to a U.S. paper size of 8.5x11.0 inches:

• VDC Type: Real
• VDC Extent (lower-left & upper-right corners): (0.,11.0) (8.5,0.)
• Scale Factor: 'metric', 25.4

In VDC space, the origin is the upper-left corner, X increases to right, Y increases down. In NVDC space, the lower-left corner coordinates (as always) are (0,0) and the upper right corner is (215.9,279.4). If (x,y) are VDC and (x',y') are NVDC, then:

• x' = 25.4*x
• y' = 279.4 - 25.4*y

Example 3: (Do we need an integer VDC Type example, maybe with a centered or non-corner origin? Or just the general case...)

In the general case, if VDC Extent coordinates are (xll, yll), (xur, yur), and Scale Factor is 'metric', s, then (x',y') NVDC is derived from (x,y) VDC by:

• x' = sign(xur-xll) * s * (x - xll)
• y' = sign(yur-yll) * s * (y - yll)

Would an illustration add anything? Or does the above suffice?

1.2 Fundamental Interfaces

[...]

clientX of type float, readonly

The horizontal coordinate at which the event occurred expressed in Normalized VDC.

clientY of type float, readonly

The vertical coordinate at which the event occurred expressed in Normalized VDC.

Does this adequately answer, "How should clientX/Y be worded?"

[...]