Getting this error when importing xml interchange file generated externally
package with uri http://www.opengroup.org/xsd/archimate not found.
I tried to export an existing model as interchange file and tried to import the same file back into Archi and still got this error.
How did you import it? Did you use the import menu item?
I used the import menu item.
The error message that you're seeing would occur if you attempt to open an exchange format file from the "Open" menu rather than the "Import" menu item. Are you sure about this?
I also got an error (using the import XML interchange option, using a XML interchange file exported with Archi from an existing model) but I also get an error when I export an existing model to csv and import it back. In the exported csv files I notice some strange indexes like "28aba5ee;e9da068b;1.6" or "=""0d13726c;e9da068b;1.6""" which seems to stop the import. The error is Invalid character found in ID: "28aba5ee;e9da068b;1.6" which is the first line with an element definition in de NonLife-elements.csv. The first three lines in that file are:
"ID";"Type";"Name";"Documentation"
"e9da068b;1.6";"ArchimateModel";"NonLife";""
"28aba5ee;e9da068b;1.6";"Capability";"Capability";""
BTW I can't share the full csv or archimate because it contains confidential information
Regards,
Peter
I think the problem that the index e9da068b;1.6 from the first line "e9da068b;1.6";"ArchimateModel";"NonLife";"" with the model definition is added to every index in the following lines in the csv file.
Regards,
Peter
Hi, the problem is using the ";" character in IDs. IDs generated by Archi don't have these, so these must have been created elsewhere.
I only use Archi for importing/exporting my models, mainly the GRAFICO plugin. For this element the GRAFICO XML info is:
<archimate:Capability
xmlns:archimate="http://www.archimatetool.com/archimate"
name="Capability"
id="28aba5ee;e9da068b;1.6"/>
Strangely enough I can still import the GRAFICO model which contains this kind of invalid indexes. I guess the bad news is that I'm now working with a model with invalid indexes :(
Regards,
Peter
So now I don't understand what generated the ID here.
BTW I've also used the database plugin in the beginning before I started to use the GRAFICO plugin so perhaps that plugin caused the strange indexes.
I will need to think of a way to start with a whole new model with rebuild valid indexes.
Regards,
Peter
I created a new model by producing .csv files with empty indexes and imported them into an emty model. But when I export the model with the newly created indexes to .csv I see again some strange indexes like "=""0f598651-017f-4de9-915c-6f9fa2057875"""
This was with the Strip newline and Excel workaround options checked during the export, and I selected to UTF8.
I could import these .csv files back into an empty model.
With the Strip newline and Excel workaround options unchecked the indexes seems to be alright with indexes like "0f598651-017f-4de9-915c-6f9fa2057875". I could import these files back into an empty model.
Regards,
Peter
Hi Peter,
I confirm that your first "bad" ids have been created by the DB plugin (I don't know exactly how, but I remember that Hervé explained that his DB plugin internally uses a concatenation of model ID, Element ID and version).
The latest ID (0f598651-017f-4de9-915c-6f9fa2057875) is ok, this is the new (long) universally uniq ID generated by Archi since beta 4 (or 5, donc rememer exactly).
Regards,
JB
Hi Jean-Baptiste,
But my latest test were done with totally new created id's within Beta 5, so I think the problem with id's like "=""0f598651-017f-4de9-915c-6f9fa2057875""" was caused by using the checked options "Strip newline and Excel workaround" during the export to cvs. I'm working on Windows 7, not sure if the behaviour is different on Linux.
Anyway, I got it working again, just lost all my relations in the whole process but I wanted to start with a clean model anyway :)
BTW I just exported all my model elements to a TiddlyWiki, see if I can combine a TiddlyWiki with Archi HTML output...
Regards,
Peter
The Excel workaround is just that - a workaround for Excel. It's not meant to be used for anything else other than getting the data into Excel, certainly not for round tripping.
Quote from: Phil Beauvoir on January 25, 2017, 21:19:40 PM
The Excel workaround is just that - a workaround for Excel. It's not meant to be used for anything else other than getting the data into Excel, certainly not for round tripping.
Yes, I think we should better explain it because people often don't understand...
In Excel (and most other spreadsheet), some magic usually happen when opening a CSV file. The most common is that if a cell content starts with one or more zero and looks like a number, then it is imported as a number, which means that those leading zero are lost. This is an obvisous issue when those cells are in fact IDs.
The workaround included in Archi makes those cells exported using the ="value" pattern. This is then understood by spreadsheet as a string value, whatever the content. But this workaround has a drawback: a CSV generated this way can't be used for import without been opened in a spreasheet and saved back in CSV. This is mandatory because it's only when saving back to CSV that the leading "=" will be removed, making it usable again in Archi.
JB
And...as I keep telling people, the real solution is to use the "Data - > From Text" option when importing CSV into Excel, not to just open it. https://www.hesa.ac.uk/support/user-guides/import-csv
Anyway, this thread seems to have veered from the original problem... :-)
Thanks for the clarification :-)
BTW I'm building my own Archi maintenance scripts now so I don't have to use Excel :-)
Regards,
Peter
Quote from: brain_work on January 25, 2017, 22:33:01 PM
Thanks for the clarification :-)
BTW I'm building my own Archi maintenance scripts now so I don't have to use Excel :-)
Regards,
Peter
What's the real, underlying, use case here? Is it manipulating the data? Is CSV just a means to get at the data? Would a scripting language provide a better solution?
I start to use scripting to manipulate data (import from other sources, export to TiddlyWiki, repair/change things in the model, simple reporting etc.). I use LINQPad (licensed version with debugger), so I personally don't need a builtin scripting language.
Regards,
Peter