cgmo-webcgm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [cgmo-webcgm] 'grnode' fixes
- From: Lofton Henderson <lofton@rockynet.com>
- To: "Bezaire, Benoit" <bbezaire@ptc.com>,"CGM Open WebCGM TC" <cgmo-webcgm@lists.oasis-open.org>
- Date: Thu, 13 Mar 2008 10:38:57 -0600
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]