• We can create link between tags in the dockerhub so that the user does not have to change the tag in the YAML file. This is only good for the application image. For example, if the tag in the YAML file is 1.2, it can keep pulling 1.2.1, 1.2.2, 1.2.3 application image, etc.
• Switching the database in the future make the data migration between versions more complicated.
• We talked about MySQL database switch. It is concluded that the application does not rely on any Oracle specific feature anymore. And going forward, it does not look like we need Oracle DB specific feature for future functionalities. ** MySQL does not have hierarchical query. Postgres has hierarchical query. ** Postgres does not have CLOB search but we don't use it now. ** I may not be easy do multi-tenant using MySQL. ** Data migration with MySQL is easier because it can ignore foreign key constraints. Oracle cannot. ** Hukju will research more about multi-tenant with MySQL to see if there is a plausible path.

• Going forward we should tag docker image with .x convention, e.g., 2.x.
• Hakju will look into fixing the last part of docker installation guide about cleaning up data volume.
  • Why don't we just tell the user to delete the VM.
• Serm will work more on classifying issues into milestones. We will have another 1.x milestone and we have created 2.x project.

Issue priority #500, #486, #487, #488

• Token <-> xsd:language
• String <-> xsd:anyURI

• End user can only edit its own module. => Change to "an end user can edit any end user’s module".
• OAGIS user can edit any OAGIS module.
• OAGIS user can edit End user module. => Disable this.
• Enhancement
  • Show the module info as a tree table.
  • Allow copy/paste
  • Cannot create folder separately because we don’t store folder. A folder has to be created as part of the module creation.

• Change to the logic when deleting a draft release -> When deleting a draft release the user has an option to push the state of all the changes included in the release back to the candidate state. The user can then take any of them back to the editing state and delete.
• What happen when there are multiple draft releases? Is deletion of the non-latest draft release allowed?
• When picking components into the release, if there are multiple revisions during the release only the latest one is shown for picking. The previous revision is left untouched, i.e., kept for record.

• We spent a lot of time talking about changing the location of the association. We found that if we only allow R1 of the association that is in editing state to be moved, we should be able to support that without creating revisions of unmoved associations.
• We also took into consideration the need for association deletion, which may occur even with the backward compatibility change intention such as the case of refactoring an association to a based ACC. We thought that there is no way to support this without revising the ACC and its associations altogether. I.e., how do we know, in which ACC revision the association was deleted. But it seems like this can cause the problem even when an association or ASCCP or BCCP is revised multiple time during the release as well - and just checking out all the associations along with an ACC is not gonna solve this situation. We still need to think more about this.

Maybe we cannot allow multiple revisions during a release. Or revisions that are not release should be deleted.

• Hakju has to check out whether the current version on Giotto needs an update to the expression generation.

• Hakju will adopt the ACC UoC, i.e., revising an ACC results in revising all of its associations.
• In order to solve the issue about the ambiguity associated with unreleased component revision -
  1. We will apply a new logic to update the foreign key of the history record of the (dependent) component to point to the history record of the associated (dependee) component, when the dependent component is changed to the published state. For example, an ASCCP is a dependent component of dependee ACC that the ASCCP uses.
  2. The import logic has to be updated to reflect the logic in #1 in the history record.
  3. The logic to pull the content of a CC may not need update, Hakju will review that. However, an update may be still warrant b/c of the performance benefit. Similarly, the BIE content rendering may need the same update.
  4. All these changes will be prototyped on a different branch.

• We made sure that we are on the same page for the 3 options discussed in the working group.
• Option 1 is the simplest but not that great because no backward incompatible change can be done on the revision. A new component with different GUID has to be created.
• Option 2 is confusing in Hakju opinion b/c different rules apply to UEGCC and UDCC.
• Option 3. We like this the most because the logic sounds consistent, there is a clear traceability. The drawback is the user cannot go back an revise the previous revision for older BIEs. In other words, this option assumes that the end user does not have a strong requirement to keep more than one releases of the BIEs active, once BIEs using a newer release has been started, the previous BIE release is immediately assumed to be in a maintenance state.

One Question just pop up to my mind, can there be two revisions of a UDCC with the same release_ID?

• UDCC, import of AIA EBO and search, and JSON schema generation are equally important. But for the later 2 we still need further design details and UDCC editng depends on the revision issue, so Hakju will work on the UDCC first and then UDCC. OTOH, if we are done with the design details of the AIA EBO import/search and JSON schema, we may preempt the UDCC development.