OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [cgmo-webcgm] 'grnode' fixes


Hi Lofton,
 
I agree with you regarding 2.3.1 and 5.3... let's not change that.
I guess the only remaining questions is getAppStructureById?
 
Ben


From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Thursday, March 13, 2008 4:57 PM
To: Bezaire, Benoit; CGM Open WebCGM TC
Subject: RE: [cgmo-webcgm] 'grnode' fixes

At 01:16 PM 3/13/2008 -0400, Bezaire, Benoit wrote:
[...]
Thanks for getting back to me. As I said, I'm flexible. I see where you are going, but I still think my proposal is reasonable. How about a compromise ;-)
 
The only issue I have with your proposal is the getAppStructureById. We clearly say in chapter 3 that grnode has an id, so why wouldn't that call be allowed.

I see your logic.  Although I don't see the need to have this standardized -- because you can't do anything with it after getting it -- on the other hand it doesn't bother me much. 

The proposal for setStyleProperty on a grnode bothers me a bit, because it is an active DOM manipulation targeted at grnode.  And I think that is beyond the area of ambiguity and constitutes a change to 2.0.  We would have to change at least: 

1.) 2.3.1:  "none of the facilities (properties & attributes) for attaching intelligence may be used with 'grnode'"
2.) 5.3:  "The target APS must not be of type 'grnode'." (Describing the normative rules for XCF processing -- if setSP(grnode) were allowed in DOM, then it would be allowed in XCF.)


I think you and I agree on the first ones, it's the last three that are questionable. Why not simply vote on it and that's the end of it. I don't want to drag this too long. The goal was simply to clarify the spec.

I'm satisfied to proceed that way.  I won't be at the next telecon, but you all know my opinions now.

-Lofton.


From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Thursday, March 13, 2008 12:39 PM
To: Bezaire, Benoit; CGM Open WebCGM TC
Subject: Re: [cgmo-webcgm] 'grnode' fixes

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:
Hi All,
 
I think section 3.2.1.5 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.?

-Lofton.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]