|Bezaire, Benoit||Mar 12, 2008 1:39 pm|
|Lofton Henderson||Mar 13, 2008 9:42 am|
|Bezaire, Benoit||Mar 13, 2008 10:48 am|
|Lofton Henderson||Mar 13, 2008 1:56 pm|
|Bezaire, Benoit||Mar 14, 2008 6:29 am|
|Lofton Henderson||Mar 15, 2008 9:25 am|
|Weidenbrueck, Dieter||Mar 16, 2008 10:28 am|
|Lofton Henderson||Mar 16, 2008 12:59 pm|
|Weidenbrueck, Dieter||Mar 17, 2008 1:14 am|
|Weidenbrueck, Dieter||Mar 17, 2008 1:38 am|
|Bezaire, Benoit||Mar 17, 2008 6:52 am|
|Lofton Henderson||Mar 17, 2008 5:50 pm|
|Lofton Henderson||Mar 17, 2008 5:55 pm|
|Subject:||Re: [cgmo-webcgm] 'grnode' fixes|
|From:||Lofton Henderson (lof...@rockynet.com)|
|Date:||Mar 13, 2008 9:42:40 am|
Thanks for the thorough and thoughtful analysis and contribution, Benoit.
Summary: I pretty much agree with your first-group recommendations, and somewhat disagree with second group. Specific opinions are embedded (below).
For information and reference, my basic position is: only allow the least API access to 'grnode' that is necessary for the DOM to behave well and not have any strange-exception rules about navigation, etc.
Underlying my choices/opinions is the premise: 'grnode' was added purely as a convenience to some authoring-tool makers who did not want to have to remove their private, tool-specific structuring from WebCGM instances. (I'm fine with that.)
At 02:51 PM 3/12/2008 -0400, Bezaire, Benoit wrote:
I think section 184.108.40.206 describes well our intent. 'grnode's cannot have any APS attribute other than the id but can contain geometry. In section 5.7.10 we say that a 'grnode' cannot be the target of an event. We say that partially because we don't want 'grnode's to be exposed too much. Ok.
But then there's the problem of tree traversal. Where we need to have access to grnodes to access child elements. And that raises a few questions about other APIs in the specification. Ex:
Should getAppStructureById work for 'grnode's?
Given that 'grnode' is private-structuring information (PSI), why do we need to provide this *standard* access to 'grnode'? Does it introduce any inconsistency or bizarre exception situation if we answer NO?
Can I apply styles to 'grnodes', they are not attributes after all?
Given that 'grnode' is PSI, why do we need to provide this *standard* access to it? I suggest NO. (More: if the authoring tool wanted the standard user to be able to hang Style Properties at that node, it should have made a standard 'grobject' there.)
I'd like to propose the following changes:
I like all of this following first group of clarifications, and will proceed to implement as you suggest. (Unless someone objects soon.)
-remove in section 5.3: 'grnode' elements are not accessible via DOM calls. Reason: they are accessible via .nextSibling, .firstChild etc... -add to the first para of 5.7.6: The WebCGMAppStructure interface has limited impact on Application Structures of type @grnode. Please see each method for more detail. -add to getAppStructureAttr Return value: The returned value is always an empty string for APS of type 'grnode'. -add to setAppStructureAttr: This method has no effect on APS of type 'grnode'. -add to removeAppStructureAttr: This method has no effect on APS of type 'grnode'.
and now the tricky ones ;-)
-I think we should allow style properties on 'grnode'.
I think NO, for the reason I wrote above, paraphrased: "Given that 'grnode' is PSI ... should have put a standard 'grobject' there. Why should we provide this *standard* access to PSI?
-I think we should allow toNodeList on 'grnode' -I think getExtent should be allowed on 'grnode'.
About these two, I don't feel as strongly as about hanging SPs on 'grnode', but again the question: "Given that 'grnode' is PSI ... should have put a standard 'grobject' there if you wanted to support these functions. Why should we provide this *standard* access to PSI?"
Less strongly than about Style Properties, but I suggest NO, for the same reasons. Why support standard-access functions on these private structures, except to the extent to avoid bizarre special rules in the DOM? (Mostly for navigation/traversal.)
I don't feel strongly about the last three. I simply think it is a clear model: 'grnode' can contain geometry, therefore it has an extent and you can style its content. If people don't like it, I can be convinced otherwise.
Likewise, I don't (yet) feel strongly. But I opt for a model that is also clear, but maximally restrictive on 'grnode'. Once again my basic position is: 'grnode' is something that is internal and private to PTC, or to SDI, or to Larson, or to Ematek, or to... Why provide any more *standard* DOM visibility/access than the bare minimum that is necessary to prevent bizarre navigation effects, etc.?