RE: [cgmo-webcgm] New draft snapshot

[Lofton Henderson <lofton@rockynet.com>]

At 10:15 PM 8/10/2004 +0200, Dieter Weidenbrueck wrote:
> Hi
> Lofton,
>  
> here is what we discussed,

Hmmm, was I at this meeting?  ;)

> and
> what the DOM should reflect:

I guess I forgot these details (and the minutes do not have that level of
detail).

This breakdown (following) should *definitely* be in the WebCGM document
(assuming that everyone agrees that it's what we decided).

>  
> - Standard WebCGM objects are
> readonly (i.e. grobject etc)
>     This means
> that no new grobjects will be created, even if they are found in the
> companion file.
>     The purpose
> is to associate information with existing objects where
> possible.
> - Standard WebCGM attributes
> are read/writeable (e.g. screentip)
>    
> obviously
> - Namespaced attributes on
> standard WebCGM objects are read/writeable
>     see my
> explanation in last email

This is setting off some dimly remembered alarm.  Did we discuss
constraints, to prevent against people sneaking private graphical
attributes in here, on standard WebCGM objects?

> -
> Namespaced objects can be created using a companion file but not the
> DOM
> - Namespaced attributes on
> namespaced objects are read/writeable
>  
> So "no new nodes"
> means that no new grobjects will be created if information is found in
> the companion file that does not relate to any existing object in the CGM
> file.
>  
> I guess this is what the
> intention was, 

Did we write it down anywhere, or was it on flip charts, or ... (i.e., is
this memory record or written record?).

> and
> again, the documents need to reflect this.

Definitely! 

(In addition, it might be good to add some informative support for those
above rules -- on the surface, and lacking background, they might strike
one as odd choices.  Rationale and/or examples and/or use cases
would be good.)

-Lofton.

 
Dieter

-----Original Message-----

From: Lofton Henderson [mailto:lofton@rockynet.com]

Sent: Tuesday, August 10, 2004 8:05 PM

To: dieter@itedo.com

Cc: CGM Open WebCGM TC

Subject: RE: [cgmo-webcgm] New draft snapshot

Dieter,

Okay, I understand your use case.  I need to think about it to decide if I agree that it should be supported.  (Maybe we should discuss in telecon.)

Let me ask a related question.  What about the "no new Nodes into the object model statement".  Does this contradict that?  Our am I thinking of "node" in the wrong sense, i.e., in the Xpath sense where an attribute is a node in the structure tree?

Another question.  If the use case is valid for adding an attribute to foreign elements (application metadata from XML companion file), then is the use case of adding new foreign elements also just as valid?

(I haven't checked, actually, to see whether this is supported or not in the WDOM.  But I don't remember it.)

-Lofton.

At 07:04 PM 8/10/2004 +0200, Dieter Weidenbrueck wrote:

[...]

4.)  Substantive:

-----

setAttributeNS:  Why have this?  You said (below),

"- Added setAttributeNS().  We were able to set WebCGM attributes but

  not the non-WebCGM one." 

What is an example usage scenario?  It would
apparently be there for adding private (application metadata) attributes
to private (application metadata) elements coming from XML Companion
files.  Why?  In sec 1.1.b we say, "The WebCGM DOM could
almost be perceived as a 'readonly' DOM. It is true that some methods on
interfaces allow users to change an Application Structure style but,
unlike the DOM Level 3 specification, it does not allow for removal or
insertion of new Nodes into the object model."  The changing of
APS styles is a transient effect for (graphical) viewing and interaction
feedback.  The changes can't (apparently) be serialized into a
changed WebCGM instance or changed XML Companion file -- this WDOM is not
an authoring/editing facility.  So ... I don't understand the use
case for this.

[DW] assume that ATA uses a
namespace attribute ata:state_of_fuse in a wiring application. At
runtime, they want to blow the fuse by clicking on it or similar. 
To keep track of the change, they would want to use setAttributeNS on
this attribute to set the new state. 
In other words: If we want to set a screentip (which is a standard WebCGM
attribute) at runtime, then people using their own namespace want to be
able 
to do the same with their attributes, for the same reason. 
<snip> 
Cheers, 
Dieter