Actions

Vagrant

Create list of instructions for vagrant provisioning script for documentation / publishing env. Sebastian to build and test.

MagicDraw

Do a test to see if MD XMI includes all model content including diagrams.

Do a test to transfer full model to another tool.

GDL

ROng - send TB XMI of GDL model.

Publishing / Workflow

Asciidoc or other generic small types - use a 'collector' CR on each release e.g. 'Correct Asciidoc syntax errors' - e.g. SPECPUB JIRA project.

Signficant CR-driven changes:

• agree on private fork + change + pull request + merge

1.  Changes is done one personal fork 
2.  Pull request is sent to main repository 
3. Owner of that specification Git repo will do the merge 
4. Each commit must be assigned with a prefix for the JIRA item (e.g. SPECRM-35)

UML changes - discuss/agree in JIRA, then component owner does or delegates UML changes to one person - avoid competing UML model changes.

Review workflow options - e.g. external reviewers:

• Component owner does
  • AsciidoctorFX export to ODT
  • generate HTML in the normal Asciidoctor way
• reviewer uses e.g. OpenOffice to markup - comments & changes, then returns to owner who then processes manually.

Git branch philosophy

• option #1 - single master
• option #2 - master = dev branch; create interim branches on demand if need to apply selected later commits at an earlier point.

ITS strategy

Per-component ITS-RM, ITS-AM, etc Git repos with file structures like:

ITS-RM repo:

• tag point: 1.0.2
  • CHANGELOG.txt
    
  • xml
    • xsd
• tag point: 1.0.3
  • CHANGELOG.txt
    
  • xml
    • xsd
      
      • 6 files
    • xslt
• tag point: 1.0.4
  • CHANGELOG.txt
  • doc
    • sdfsdfdf
  • xml
    • xsd
      • 6 files
    • schematron
      • 2 files
    • xslt
      • xxx
    • examples
      • xxxx
  • json 
    • xxx

Each repo would use same tags as SPECIFICATION-xx repos, e.g. 'Release-1.0.3'. 

To add updates to an earlier release, e.g. fix 1.0.2 XSD bug, or add JSON schema to 1.0.2, then do a branch off the relevant tag point and use tags like 'Release-1.0.3-R2' etc.

Can also add secondary 'bundle-based' tags e.g. '2016.3', '2017.6' etc.

Manually maintained CHANGELOG.txt file in root - enables consumers to easily find out what has changed.

Long term release?

Additionally, a 'whole of system' ITS repo containing e.g. whole of system documentation, packaging scripts etc.

Conformance

Release naming: use e.g. openEHR-2016.3?

Question: how to connect conformance resources/test plans etc to ITS artifacts.

Idea of 'conformance to openEHR-2016.3'...

AQL functions

Generic need for 'functions' in AQL / extension mechanism

Need to show how to define RM-independent functions e.g. math functions, 

Then need ability to define RM-specific functions e.g. instruction-aggregate-state() , etc see pres from Bjørn Næss 

Latter would be specified .... where?

Implementation guidance for AQL service implementers

also consider 'service view' of functions, i.e. REST access as well as AQL access.