Well I have a design in place…I have a set of actions that describe how things are to be done.  The “create element” action is the only one where the entire element is sent.  There are optional attributes for the action; a “parentId” that describes which element the new element is to be appended to (root element, g element, etc.) and a “beforeId” that can specifically describe which element the new element will be inserted before (Node.insertBefore(…)).  Moves, updates and deletions work like you describe.  You find the element by its ID and apply modifications.


To send the outgoing message, I use XMLBeans to transform the Element to an XmlObject which can be represented as a String.  Now I need to do the reverse, but I don’t think XMLBeans can do it, so I need to find another way.  I’d hate to use a SAXParser to parse the element into a new document, then do a copy from one document to another.  I’d rather import it directly into the client document.


Maybe another approach would be the “create element” message has a different structure?


-          Tag name.

-          Namespace.

-          Collection of attributes.

-          (Optional) parentId.

-          (Optional) beforeId.


I posted here because I thought maybe someone had done something like this before; most of the stuff I’ve undertaken for this project has been a learning experience.  I haven’t done anything similar to this previously.


Michael Bishop


From: dvholten@computer.org [mailto:dvholten@computer.org]
Sent: Monday, March 13, 2006 1:36 PM
To: batik-users@xmlgraphics.apache.org
Subject: Antwort: String to SVGElement?



that looks like a tricky problem. I see no simple solution.
If I would have to design something like this I would try to go this direction:
- master and slaves (clients) start with the same document. So all have the same structure and id's.
- i would try to detect changes in the master element's attributes and propagate just that: id, attribute and new value.
- on client-side, I would locate the element by id and change the attribute.

A problem is structural changes: where to put new elements? When they are within a <g> ?
That may be possible when you send the parent's id...

So it can be reduced to some basic operations:
- insert new element under a parent-element
- delete element(id) ( plus it's children)
- modify element-attributes
- add/delete attributes(?)

Maybe it's simpler to distribute the modification-commands (which create the dom-modifications)
and do the same modifications in the clients.

DOM consistency is quite a challenge: namespace-things, valid attribute-values....

If you can give some more details we may provide some more ideas.