Re: [cgmo-webcgm] Re:

[Benoit Bezaire <benoit@itedo.com>]

Hi Lofton,

Thank you for the comments, see inline.

Tuesday, July 6, 2004, 6:40:05 PM, Lofton wrote:
LH> Ben,

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

LH> 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?

LH> Hmmm... examples or use cases (anyone) for whitespace handling?
I'm proposing to remove any methods regarding whitespace handling from
the specification for now.  People know about the issue, if someone
has a good use case; I will be more than happy to put it back in.

>>   -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().

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

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

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

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

LH> (Question...  I don't recall -- what if anything does standard DOM2/3 say
LH> about it?)
I'll have to check, I'm really not an expert on this matter.  If
someone had a small example we could all look at, it could help.

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

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

LH> Do people agree or disagree?

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

LH> Else -- i.e., if we were to decide that the DOM text size is supposed to be
LH> typical typographical practice, and not CGM-specific sizing model, -- then
LH> perhaps "pt" would be a good idea.  It would reinforce that this is *not*
LH> the text size of the CGM text model.
I 'agree'.  The next draft will contain % only.  Same thing as I said
before, if someone has a good use case, we can always talk about it.

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

LH> (no opinion now ... maybe later)
Dieter and I talked about this one a bit.  We don't think we need
relatedTarget, target should be sufficient.  The changes will be in
the next draft (with explanations).

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

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

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

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

LH> "WebCGM user space" suggests VDC to me.  On other interfaces and methods,
LH> haven't we decided that VDC should be avoided, because VDC require the
LH> context of VDC Extent?
Right, I know we agreed to have (0,0) at the bottom left section of
the illustration... but what are the (right,top) values?

LH> 2.) You asked, "What does WebCGM say about Whitespace handling, would this
LH> be useful to us?".  Answer.  It doesn't say anything yet.  WebCGM is
LH> binary.  Whitespace issues are an artifact of clear text encodings like
LH> XML.  There is no XML component to WebCGM 1.0 definition, other than the
LH> new in-progress XML Companion File.
So, in my opinion, if the current spec doesn't say anything about it;
I don't think the DOM should introduce the concept.

LH> All for now,
LH> -Lofton.
Thanks!

-- 
 Benoit   mailto:benoit@itedo.com