[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cgmo-webcgm] Re:
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]