'grnode' clarifications

[Lofton Henderson <lofton@rockynet.com>]

Benoit pointed out several loose ends about 'grnode' in his review. 
We had two earlier threads, apparently reached some conclusions, and left
the final resolution for this 60-day review period.

Thanks to Benoit for his thoughtful review comments, here and in the
earlier threads!

ISSUES/QUESTIONS:  Here are Benoit's CD01 comments/questions
==========

GRN-1:
http://lists.oasis-open.org/archives/cgmo-webcgm/200805/msg00011.html
At 10:06 AM 5/6/2008 -0400, Bezaire, Benoit wrote:
> 3.2.1.5
> Grnode: should we clarfiy in here if 'grnode' has a bounding box (i.e.,
> geometry)? Supports styling?

GRN-2:
http://lists.oasis-open.org/archives/cgmo-webcgm/200805/msg00012.html
At 10:10 AM 5/6/2008 -0400, Bezaire, Benoit wrote:
> It's
> unclear from section 4.3.10 if 'bindById' can reference 'grnode's, we
> should clarify.

GRN-3:
http://lists.oasis-open.org/archives/cgmo-webcgm/200805/msg00013.html
At 11:30 AM 5/6/2008 -0400, Bezaire, Benoit wrote:
> 5.3: I
> think we should change - The target APS must not be of type 'grnode'.
> 'grnode' elements are not accessible via DOM calls. - 
> with
> : The target APS must not be of type 'grnode'.
> 'grnode' elements are not accessible via the XCF in this version of
> WebCGM.
>  
> 5.7.4: Should we add a general statement here
> to say that 'grnode's can be accessed via the WebCGMNode
> interface?
>  
> 5.7.5: 
> getAppStructureById, it's unclear if 'grnode's
> can be retrived by the method, we should
> clarify.

PREVIOUS THREADS:
==========

In two previous threads, we explored the references in the 2.0 document,
which taken together indicate that 'grnode' was intended to be highly
inaccessible through most DOM/XCF functions when it was added to 2.0.

'grnode' was added to 2.0 after very intense debate, and its sole purpose
was to allow WebCGM editors to preserve private, application-specific
structuring (grouping) in the metafile.  There would be no
standardized semantics or functionality.

[T1]
http://lists.oasis-open.org/archives/cgmo-webcgm/200803/msg00041.html
[T2]
http://lists.oasis-open.org/archives/cgmo-webcgm/200803/msg00062.html

In thread [T1], Benoit, Lofton, and Dieter agreed that 'grnode' could not
be *completely* invisible to DOM/XCF.  Specifically, Dieter pointed
out that the tree navigation breaks if 'grnode' were invisible to the
parent/sibling/child navigation stuff in Interface WebCGMNode.

Lofton asserted in [T1], "it is unambiguous that we intended
'grnode' to be *almost* DOM-invisible."  Specific improvements
to the document were not addressed in [T1].

Everyone should read [T2].  Benoit proposes a list of specific
changes at message [T2], and there is detailed discussion in the thread.

Dieter requests [D1] in the thread that there be a clearly defined
behavior for each place that 'grnode' might be invalidly used.  One
of (TBD):  simply ignore; return error code; throw
exception.

RECOMMENDATIONS:
==========

My basic position remains:  Given that 'grnode' is
private-structuring information, why provide any *standard* access to
'grnode', other than what is necessary to avoid breakage, inconsistency
or bizarre exception situations in DOM/XCF.  [IMO, this now means
only the navigation stuff.]

Here is Benoit's original list of proposals from [T2]:

> [B1] -remove in section 5.3:
> 'grnode' elements are not accessible via DOM calls. Reason: they are
> accessible via .nextSibling, .firstChild etc...

Rec:  Modify it, similar to Benoit's suggestion in GRN-3 above, to
indicate that what you can do with 'grnode' is severely 
limited.

> [B2] -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.

Rec:  I don't mind -- something along these lines is probably
useful.

> [B3] -add to getAppStructureAttr
> Return value: The returned value is always an empty string for APS of
> type 'grnode'.

Rec:  Okay.

> [B4] -add to setAppStructureAttr:
> This method has no effect on APS of type 'grnode'.

Rec:  Okay.

> [B5] -add to
> removeAppStructureAttr: This method has no effect on APS of type
> 'grnode'.

Rec:  Okay.

> [B6] -I think we should allow style
> properties on 'grnode'.  

Rec:  No.  (This also addresses GRN-1 above.)

> [B7] -I think we should allow
> toNodeList on 'grnode'

Rec:  No

> [B8] -I think getExtent should be
> allowed on 'grnode'.

Rec:  No.  (This also addresses GRN-1 above.)

> [B9] Should getAppStructureById
> work for 'grnode's?

Rec:  No.  (This also answers GRN-3 above.)

> [GRN-2] (above): 
> It's unclear from section 4.3.10 if 'bindById'
> can reference 'grnode's, we should clarify.

Rec:  No.

> [D1] When 'grnode' is used in
> invalid way, should the DOM:  simply ignore; return error code;
> throw exception?

Rec:  None recommendation yet.  I'd like to hear more from
users and vendors.

SUMMARY:  
==========

I have taken a consistently strict approach.  Stick as close as
possible to original "almost DOM-invisible" intent. 
Deviate only to prevent breaking DOM navigation, or other bizarre side
effects. Don't argue the merits of these things case-by-case -- 'grnode'
is private round-tripping information.  

I don't yet have an opinion on Dieter's question about whether invalid
'grnode' usage should result in ignore, or in error code, or in throw
exception.

Thoughts?  Feedback needed, on any and all of this, especially from
outside of the present threads of Benoit/Dieter/Lofton.

-Lofton.