cgmo-webcgm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [cgmo-webcgm] request for new style propertity
- From: "Bezaire, Benoit" <bbezaire@ptc.com>
- To: "WebCGM" <cgmo-webcgm@lists.oasis-open.org>
- Date: Wed, 8 Oct 2008 13:33:40 -0400
Hi,
I have a hard time understanding why a new style
property is needed. Maybe I'm missing something, but a 'state' property sounds
like metadata to me.
Why can't the state of the objects be kept in JS
variables; or alternatively into namespace attributes set/getAttributeNS (on
WebCGMNode interface)?
Benoit
All,
quite honestly, I don't understand Forrest's
request.
"I would like to propose an additional
style property for WebCGM 2.1. This would be a generic text string that could be
used to define the state of an application structure. Values might be 5 volts ,
30 psi , switch position 3 , etc. In my example I have used state as the name of
the style property, but some other name like comment would also
work."
This sounds like a generic APSATTR of type string. However,
Forrest apparently suggests to use this attribute to describe a "state" listing
several examples. These examples suggest an implied semantics that can not be
understood without ambiguity.
Example:
an APSATTR with the name "Voltage" could carry a string or
numeric value of "5". The semantic of this attribute would have to be clearly
defined so that an interpreter would know what to do with it. However, as there
is no built-in logic for such a semantic, e.g. "hide an object and show another
one depending on this value", it would be difficult to standardize the
viewer behavior.
But in this case, it is even worse, there is not even a
clearly to be understood value, it may be anything.
So there is no way
- for the interpreter to understand the
semantics
- for the interpreter to act
accordingly
Now one could say, why not treat it as an arbitrary text
attribute?
The reason is that then we're back to the old times, where
Forrest would probably carry a voltage around for an interactive wiring diagram,
Don might put some seismic value into it, and we might do something completely
different with this attribute.
This would put us right into a situation, where only one
application would understand it and do the right thing, whereas a
standards-compliant viewer would have no chance to handle the intended
functionality accordingly.
Therefore, I object to this, unless I have completely
misunderstood the intention.
Regards,
Dieter
Stuart -- please put this on the agenda for discussion.
All --
(Email discussion is also welcome, of course.)
Per the principles
that I expressed in a just-sent message [1], I think a wise approach for
comments like this is: TC reach consensus about Forrest's comment;
then, Forrest send his comment (possibly revised) to the W3C public list for the
Last Call review in the WebCGM WG.
Of course Forrest is free to process
his comment in any way he pleases, since the spec is now under WG control, but
some up-front coordination might help expedite the completion of the OASIS-W3C
collaboration on 2.1. (See [1] for further explanation.)
[1] http://lists.oasis-open.org/archives/cgmo-webcgm/200810/msg00007.html
Regards,
-Lofton.
At
12:06 PM 10/7/2008 -0500, Forrest Carpenter wrote:
All,
I would like to propose an additional style property for
WebCGM 2.1. This would be a generic text string that could be used to define
the state of an application structure. Values might be 5 volts , 30 psi ,
switch position 3 , etc. In my example I have used state as the name of the
style property, but some other name like comment would also
work.
Regards,
Forrest
---------------------------------------------------------------------
To
unsubscribe from this mail list, you must leave the OASIS TC that
generates
this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]