Hi @sudhirkumra , re the missing xml … In order to include xml as written text in the forum, you need to mark it as “pre-formatted text”, using the toolbar button, otherwise the forum software gives it “special treatment” and it gets corrupted/disappears.
Unfortunately I don’t currently have any simple solutions to this new problem. The initial question was how to update XML, which has been achieved.
The new question is how to update XML in a specific way so that it works with the ARCHI tool. All of the XML “rewriting” is being performed by the standard KNIME nodes and as far as I can see they are writing valid XML.
Of course I don’t have full copies of the XML you are looking at, and no way of testing the end result, nor even knowing what the full end result needs to look like (without what would we be a lot of time spent trying to manually read an XSD) .
I visited the opengroup.org website which hosts the ArchiMate XSD and I found the statement on their front page, that their “standards ensure openness, interoperability, and consensus” to be a little ironic given the situation you find yourself in, which makes me wonder if there is actually some other issue here but I don’t know what it would be.
Closing of non-group elements on same line
Have you looked to see if the closing of the element tag on the same line requires it to be of the form
<color r="0" g="0" b="0" />
or whether the following is also permissible:
<color r="0" g="0" b="0"></color>
It’s possible that a piece of java, python or possibly even String Manipulation in some loops might be able to convert these close tags in the final output prior to writing to a text file, provided the actual requirement is known.
Attribute order
Can you confirm definitively that the attribute order actually makes a difference?
e.g. does it have to be:
<color r="0" g="0" b="0" />
or can it be
<color b="0" g="0" r="0" />
KNIME’s XML nodes (such as XML Reader and String to XML) generate attributes in alphabetical order which is a perfectly valid thing to do, except when the destination system won’t accept it!
I have no way of controlling what KNIME will do in terms of attribute sequence. I see that this has come up before, and a possible idea put forward, but in my view this is a non-trivial problem which would take a lot of working out (and a lot of testing):
My thoughts are that the xml that is generated at the end of the workflow would need to be interpreted using an XML parser, and you would have to explicitly define the order of every attribute. This could possibly be determined by reading the order as they appear in the XSD (but that in itself is not a trivial problem as you’d first have to also write an XSD parser to understand what is a relatively complicated XSD!)
So right now I don’t have a solution to this part of your problem.
I would suggest that for this part, a new forum thread should be started as it is a totally different question to “Update XML with some value in a tag based on ID”, as you are looking for “A way of re-writing an existing XML with specific control over the way tags are closed and the order in which attributes are written”. It is possible that people who may have some ideas on this are no longer following this particular thread.
If I can think of anything I will also chip in.