Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FCP_018: Add specified extra meta-data directory to FMU ZIP archive structure #585

Open
pmai opened this issue Jun 26, 2019 · 6 comments

Comments

Projects
None yet
4 participants
@pmai
Copy link
Collaborator

commented Jun 26, 2019

The SSP standard added a specified location for additional meta-data to SSP packages in the form of an extra directory with sub-directories using reverse domain notation. This allows tools handling SSPs (including but not restricted to SSP creators) to read, add, modify or delete additional meta-data to the SSP that should travel with the SSP in a specified location that avoids clashes and clearly states processing expectations. This mechanism can be used for layered standards and other domain-specific solutions, similar to, but going beyond, the (vendor) annotation mechanism.

This FCP proposes to add the same mechanism to FMI 3.0 for FMUs, in exactly the same way.

This can for example be used to add standardized meta-data, like the SMMD format meta-data to FMUs in a direct way, but it can also be useful for many other extensions.

A pull request with the actual wording change is upcoming.

@masoud-najafi

This comment has been minimized.

Copy link
Collaborator

commented Jun 26, 2019

Could this new directory be used as a folder for storing generated data by the FMU?

@chrbertsch

This comment has been minimized.

Copy link
Collaborator

commented Jun 26, 2019

This proposal for a new subfolder in the FMU zip-File shall also be aligned with the proposal for an eFMU container from the EMPHYSIS project. One could use extra/eFMU
I will forward this ticket to the EMPHYSIS Project.

A general question: Without this FCP: is an FMU containing a subfolder in the zip-File that is not mentioned in the specification a valid FMU? Or would this only be allowed for subfolders of the docuementation folder (that could contain any content)?

@pmai

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 5, 2019

@masoud-najafi The FMU has no way of storing stuff somewhere into the FMU, since it will only have access to the unpacked (parts) of the content. There is no requirement that FMU importers update the FMU from stuff written to the unpacked parts.

Also, if the FMU wants to access stuff at runtime, it has to place it into resources, since that's the only part that is required to be available.

@pmai

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 5, 2019

@chrbertsch I think that FMUs can already contain more directories than mentioned in the ZIP structure, without becoming invalid. The extra directory is intended especially for tools other than the original FMU generator to find and/or add new stuff reliably.

@pmai

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 5, 2019

@chrbertsch As to EMPHYSIS: Yes, if we adopt this FCP, they could use something under extra, but in order to comply, it must use reverse domain notation of a domain under their control, so should be something like extra/org.fmi-standard.eFMU (if approved by MAP FMI), or extra/org.wherever-emphysis-lives.eFMU, or something of that nature. The whole idea being that there are no inadvertent clashes under extra.

@MartinOtter

This comment has been minimized.

Copy link
Member

commented Jul 11, 2019

What is the difference between a resources and an extra directory. It seems that the reverse domain notation to avoid name clashes could also be used in the resources directory

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.