Re:

[Lofton Henderson <lofton@rockynet.com>]

Ben,

Nice work.  I have a few comments, embedded.  (I haven't had enough time to 
really study the new document, so maybe more later.)

At 12:21 PM 6/23/2004 -0400, Benoit Bezaire wrote:
>Hi all,
>
>   Attached you will find the latest version of the WebCGM DOM spec.
>
>   What's new in this version...
>   -Added the Event interface.
>   -Added the EventListener interface.
>   -Added the addEventListener method to the Picture interface.
>   -Added the Hyperlink interface.
>   -Added the DOMStringList interface.
>   -Changed the METADATA_ELEMENT_NODE type to XML_METADATA_NODE.
>   -Added wording to sections 1.1.b, 1.1.2 and 1.2
>
>   Questions that need to be answered...
>   -Should the DOM be able to handle whitespaces?  Do you think that
>   specialized applications (wiring or others) will include
>   xml:space="preserve" in the XML companion file?  What are the user
>   expectations regarding to this?

Hmmm... examples or use cases (anyone) for whitespace handling?


>   -What happens if we are listening to the 'click' event on an object
>   that has a linkuri attribute on it?  Are both executed, which one
>   comes first?  Do we need the preventDefault() method to handle this
>   or just a set of rules, please refer to the DOM Level 2 spec for
>   more info on preventDefault().

In your document "WebCGM Events.htm", you made a three-bullet proposal 
about this, and preventDefault() was a feature of the proposal.  I don't 
recall any dissent, and it seemed to me to solve the question nicely enough.

So I thought we had endorsed it.  Does anyone object?  (We must be getting 
close to "last chance!")


>   -How should we deal with entities in XML companion file?  Is a
>   viewer suppose to resolve them?

If entities are allowed, then I think "yes".  Suppose the viewer DOM 
implementation builds and maintains the DOM tree including the application 
metadata.  If entities have been used in the latter, how can the DOM 
implementation possibly be of any use if the entities aren't resolved?

(Question...  I don't recall -- what if anything does standard DOM2/3 say 
about it?)


>   -Should we allow the character-height to be expressed in pt?

I see no reason for this, and one possible reason against. CGM Character 
Height measures the baseline-capline distance of the text.  I have assumed 
(implicitly, without actually thinking about it) that the text size in the 
DOM interface is the same as in CGM, i.e., Character Height.

Do people agree or disagree?

If "agree", then we should *not* confuse the matter with different units 
than everything else (we're measuring everything else in 
mm-rel-to-displayed viewport, or %).  Pt invites you to think of typical 
typography text size.  (This was perhaps one of the most persistent early 
implementation errors of CGM Version 1.)

Else -- i.e., if we were to decide that the DOM text size is supposed to be 
typical typographical practice, and not CGM-specific sizing model, -- then 
perhaps "pt" would be a good idea.  It would reinforce that this is *not* 
the text size of the CGM text model.


>   -Do we need relatedTarget on the Event interface?  I believe that
>   some of the existing API offer something like this?  Is it needed,
>   is it useful?

(no opinion now ... maybe later)


>   What's still missing...
>   -The XML companion file DTD. (Dave)
>   -Picture of architecture. (Benoit)

Dave had an interesting animated PPT.  From that, I had the idea that we 
might do better than a single static picture.  E.g., "cartoon panel" style 
with a sequence of 3-4 pictures and some accompanying narrative.

>   -Wording for the Highlight() method. (all)
>   -More comments on the spec. (all)

1.)  On Interface Event, I noticed this:  "clientX of type float, 
readonly.  The horizontal coordinate at which the event occurred expressed 
in WebCGM user space."  Similarly for clientY.

"WebCGM user space" suggests VDC to me.  On other interfaces and methods, 
haven't we decided that VDC should be avoided, because VDC require the 
context of VDC Extent?

2.) You asked, "What does WebCGM say about Whitespace handling, would this 
be useful to us?".  Answer.  It doesn't say anything yet.  WebCGM is 
binary.  Whitespace issues are an artifact of clear text encodings like 
XML.  There is no XML component to WebCGM 1.0 definition, other than the 
new in-progress XML Companion File.

All for now,
-Lofton.