cgmo-webcgm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [cgmo-webcgm] 'grnode' clarifications
- From: "Bezaire, Benoit" <bbezaire@ptc.com>
- To: <cgmo-webcgm@lists.oasis-open.org>
- Date: Mon, 12 May 2008 09:22:19 -0400
Thanks for the summary Lofton.
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]