RE: [cgmo-webcgm] 'grnode' fixes

[Lofton Henderson <lofton@rockynet.com>]

I may be misunderstanding Dieter's point, but here are my
comments...

At 01:28 PM 3/16/2008 -0400, Weidenbrueck, Dieter wrote:
>  
> I think we have to look at
> grnodes also from a different perspective.
>  
> _ALL_ DOM calls must work with
> grnodes in a sense that there must be a precise behavior in case a grnode
> object is used with any of the calls.

I'm not sure that I agree.  What you are talking about is
essentially exception or error handling policy.

>  
> Example:
> If somebody builds a nodelist
> using GetSibling or similar, he will potentially end up with a list that
> contains grnodes. If then he starts using that list with other DOM calls,
> these grnodes will be used as well, unless we want to force the
> scriptwriter to examine each object before making the
> call.

IMO, that is the way we purposely wrote WebCGM 2.0.  'Grnode' is
proscribed from most DOM/XCF manipulation that is allowed for other APS
types. 

> Even
> if we would expect this to happen, we have to deal with the situation
> that somebody does it anyway, and the viewer must respond in a
> predictable and well-defined way.

I don't agree with the last statement.  If you look throughout the
CGM standard, and the WebCGM profile, it (mostly) does not say what a
viewer does with invalid input.  It does not tell the viewer what to
do with an invalid, non-existent linetype, for example.  It only
defines valid content/input, and what the viewer does with valid
input.

I'm sure we can find a few exceptions somewhere in WebCGM (e.g., some
Exception stuff in DOM sections), but that is the overall philosophy that
has been around ever since CGM:1999 and WebCGM 1.0.  See for example
T.26.8 here:

http://docs.oasis-open.org/webcgm/v2.0/OS/WebCGM20-Profile.html#webcgm_4_15

>  I
> am not sure whether this is currently covered in the
> spec.

...only in the general statement of error / exception policy of
T.26.8.

That said ... I guess it is a valid issue whether we want to extend the
currently minimal DOM Exception stuff to cover 'grnode' as the invalid
target of DOM or XCF actions.

Regards,
-Lofton.

---

From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Samstag, 15. März 2008 17:25
To: Bezaire, Benoit; CGM Open WebCGM TC
Subject: RE: [cgmo-webcgm] 'grnode' fixes

At 09:29 AM 3/14/2008 -0400, Bezaire, Benoit wrote:

[...]
I agree with you regarding 2.3.1 and 5.3... let's not change that.
I guess the only remaining questions is getAppStructureById?

I'm mildly against it, just because it seems sort of useless -- after "get", you can't really do anything with it. 

However, if someone wants it and has a useful scenario for it, or if its absence would cause some bizarre inconsistency in the DOM, then I wouldn't object.

-Lofton.

---

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.