Nick reviewed the Standards Ratification Process approved at last Friday's FDC3 PMC Meeting. Very briefly, key points are:

• WG creates a proposed standard and raises it to proposition status (ideally by consensus and if not consensus then by vote - guidance is included on quorum, active participation definition and voting procedure)
• Proposal is published for review and comment before being presented to PMC.
• Proposal is presented at FDC3 general meeting and is open for comments for 2 weeks
• If ratified by PMC the standards are versioned and published (in one place for all FDC3 ratified standards)

This only comes into play if there is a dispute or contention that requires a vote. The point is to build consensus and generate broad buy-in, with standards and the ratification process accessible to the community and appropriately recorded.

No comments from the group on the process.

https://github.com/fdc3/api/issues

https://github.com/fdc3/api/pulls

The draft specification has been in discussion and review for quite a while with a number of PRs (minor and major) merged in. 

Nick stated that his goal is to get the proposed standard to a point of completion where it can be take to a vote for ratification. There are a number of people already building against proposed standards so we want to have the baseline established and then iterate.

The group went through the following issues:

#23 - Add API usage example

Agreed code examples should be included and added to the documentation, e.g. code examples commented into the TypeScript files/generated docs. The API specification itself could also be shipped. Issue # 27 - publish NPM module for TS interface was created for this.

#22 - Specification draft refers to raiseIntent and Resolution Object

Added PR #26 to address this. Added IntentResolution and also made Context open and optional. Riko pointed out that in some instances AppIdentifier is used and in other cases String is used and this should be consistent. Some disagreement on leaving AppIdentifier “intentionally vague” for now with the decision to leave as is until/unless a specific alternate proposal is raised.

#21 - What happens if an application is opened with context?

Leslie noted that they disagree with the current approach to how “Open” works and will provide an alternate proposal.  

#20 - Resolve by context only is required

There was continued discussion around IntentMap and the possibility of sharing the Intent definition as defined by the Intents WG, with some issues still to consider/resolve around appMetadata and Context. The group agreed that they were close to agreement and would take this offline to progress.

# 17 Should name in fdc3.open be an AppIdentifier

Is it necessary to have type AppIdentifier designated or could it be a (more generic) String. Down the line if something new is required then a new version of the API spec can be created to address this. Leslie pointed out that a benefit of being in FDC3 is to have, e.g. a consistent Context definition. There is added complexity because there is no ratified Context Data specification yet. There is a strong argument for both approaches (more explicit vs more generic) and this remains an open issue. For now AppIdentifier and IntentName will be changed to String.

#16 - Generated documentation in docs folder contain paths to contributors’ forks

Very straightforward hygiene point for which there is already a PR.

Nick reiterated that the aim is to get these items cleaned up in the next two weeks in preparation for bringing this to a vote.

Leslie asked to present an alternative definition for discussion at the next meeting before existing spec goes to a vote. Nick suggested that the two were not mutually exclusive and that the group needed to move forward.

It was agreed that the new proposal and current spec should be provided to the group ahead of the next meeting to enable WG members to review before discussion in the WG meeting.