Specialization with image save archimate model in a binary form ?

Started by tpedot, December 01, 2021, 19:43:07 PM

Previous topic - Next topic

tpedot

Hello,
I start to manipulate archimate as an xml file (thanks to ecore and python :) )

But when I start using it with specialization and image, it seems that archimate file is a binary now.

Can you confirm ? Is there any workaround ?

Thanks !

Phil Beauvoir

If an Archi model contains images then the images and the model file are stored in an archive file to keep everything together (zip file format). The format is zip, so you can unzip it with a zip library or manually by changing the extension from *.archimate to *.zip.
If you value and use Archi please consider making a donation! https://www.archimatetool.com/donate

tpedot

It should work :)
What is the rational ? Space ?

I didn't saw it in the documentation. If you point me to the documentation I can make a PR for an update.

Thanks for the reactivity !

Phil Beauvoir

This is the format used when there are several files to keep together in one container archive-type file.
If you value and use Archi please consider making a donation! https://www.archimatetool.com/donate

Jean-Baptiste Sarrodie

Hi,

Some comments on this:

1/ Archi native file format (like any tool native file format) should always be considered as not usable outside the tool. People should not make any assumption on this format because Phil and I could change it at any time depending on our needs. The sole purpose of the file format is for Archi to be able to persist information for itself.

2/ As a corollary, when working on a model outside Archi, you should always use the ArchiMate Model Exchange File Format (aka Open Exchange File). This file format is designed for interoperability, is well documented and is stable. In addition, using this file format as an input makes sure your work can be used with any compliant ArchiMate modelling tool.

3/ If there's a need to automate something leveraging Archi only features that are not present in the exchange file format, I'd highly recommend to review your use cases, and if confirmed, then to use jArchi.

Regards,

JB
If you value and use Archi please consider making a donation! https://www.archimatetool.com/donate

tpedot

Hello, thanks for your feedbacks really appreciated.

1/ I understand this. At the end, if major change is to be made and we know that 'a certain' amount of time before it's ok.

2/ I always prefer those format. This just lack some features today like keeping the tree structure for exemple.

3/ Our ecosystem is made of Python: dataschemas / diff & merging / etc... So if we can make it outside...


:)

Jean-Baptiste Sarrodie

Hi,

Quote from: tpedot on December 03, 2021, 14:32:17 PM2/ I always prefer those format. This just lack some features today like keeping the tree structure for exemple.

Tree structure is supported by the Exchange file format but is named Organization (see: https://pubs.opengroup.org/architecture/archimate31-exchange-file-format-guide/#Chap07-Organizations). Archi does support it.

As The Open Group is working on the next version of the Exchange File Format, Could you list the missing features you think would be useful? I'll then see how we can address them.

Regards,

JB
If you value and use Archi please consider making a donation! https://www.archimatetool.com/donate

tpedot

Yes. I will find a time for that. I propose to open a github issue for that do you agree ?

Phil Beauvoir

Quote from: tpedot on December 03, 2021, 16:27:16 PMYes. I will find a time for that. I propose to open a github issue for that do you agree ?

Don't open a GH Archi issue if it is a general Exchange Format issue and not Archi-specific.
If you value and use Archi please consider making a donation! https://www.archimatetool.com/donate

Jean-Baptiste Sarrodie

Hi,

As Phil said, this is related to Open Group work ad not Archi itself. Simply share your wish list in this discussion and I'll share them with The Open Group myself.

JB
If you value and use Archi please consider making a donation! https://www.archimatetool.com/donate

DaveVint

Hi JB,

Just saw your request for the Exchange Format feedback. I have a couple of suggestions.

  • Better rules around the uniqueness and persistence of the IDs. IDs should be globally unique, consistent when a model is exported multiple times, and maintained if an imported model is re-exported.
  • Support for specialisation/customisation as per the main spec and (i presume) as now implemented within Archi. Many tools have some specialisations for Metrics/Risk/Security modelling that cannot be exchanged

Cheers,

Dave

Phil Beauvoir

#11
Quote from: DaveVint on February 21, 2022, 12:28:03 PMBetter rules around the uniqueness and persistence of the IDs. IDs should be globally unique, consistent when a model is exported multiple times, and maintained if an imported model is re-exported.

That simply cannot be enforced. IDs are internal to the XML file and, beyond that, depends on how the tool or service handles objects and persistence internally. And how will you stop users manually changing or creating IDs? There are no guarantees when it comes to how a tool or service manages IDs. The exchange format is like a delivery truck - it delivers the model via import and there are no guarantees what happens to it after that.
If you value and use Archi please consider making a donation! https://www.archimatetool.com/donate

DaveVint

Thanks for the feedback Phil - completely understand the lack of enforceability and variation in tooling support. But there are plenty of things already in the exchange standard that fall into that category, such as "sourceAttachment" and "targetAttachment" that I've mentioned before.

The ID suggestion has come out of the real world practicalities of using the exchange file. We have multiple semi-independent organisations using at least 4 different tools. The primary use cases are the dissemination of reference architectures and the transfer (for validation) of solutions built against those reference models. If we leave the known issues around element deletion and diagram nuances to one side, the biggest blocker we've had to this working smoothly is this ID issue. Without the persistent maintained unique ids, the reference models are snapshots that cannot be changed and the solution models cannot be checked for appropriate use of the reference architecture.

The use cases that the current format supports seem to be very limited - pretty much ok for migration from using Tool A to using Tool B instead, but not for anything more complex that might happen amongst a community of architects. [Edit to add:] Note, I'm not talking about round-tripping or anything that complex - just consistent treatment of IDs.

Archi pretty much seems to do what I proposed above. BIZZDesign does different things depending upon the circumstances - IDs in models stored locally in a file are unique only within that file whilst IDs in models stored centrally have a UUID. Can't recall what the other tools do. We're trying to work around it with some scripting, but I don't think it's always possible and even just having a separate 'exchangeID' that conforms to those rules would be of benefit.

Dave