cgmo-webcgm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [cgmo-webcgm] 'grnode' fixes
- From: "Bezaire, Benoit" <bbezaire@ptc.com>
- To: "CGM Open WebCGM TC" <cgmo-webcgm@lists.oasis-open.org>
- Date: Thu, 13 Mar 2008 13:16:21 -0400
Hi Lofton,
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 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.
Benoit.
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]