XJDF next steps
Errata editing and release process
- keep to a minimum
- only if it affects interoperability
Do we need errata releases such as 2.0.1 with updated schema and/or bug fixes only?
- Ideally we should not change the document
- Add FDF based on original PDF to the errata page
- No 2.0.1 version unless we find something that is very broken
- Add color coding definitions to errata and always use
cross-out font for removed text,
- Errata are proposed by the technicl workgroup and reviewed by the TSC prior to publication.
Do we need a registry of new NMTOKENS and return codes between versions?
- We should have an NMTOKEN registry individually for 1.6/2.0 in the specification area of confluence
- Add a description how to use JIRA to extend NMTOKENs
- Extensions are logged against the next spec version or ICS but added to the registry
XJDF 2.1 / JDF 1.7 Roadmap
1.7/2.1 Update at drupa
Focus Improvements to XJDF
Using (X)JDF in the cloud
- Rest Interface (long debates on usefulness)
- Quality Control
Retain the Technical Workgroup, and discuss all specification and ICS related topics there.
Short lifetime focus groups in the off weeks:
- Maybe cloud
Chairman election: Stefan Meissner elected.
do we keep 2 separate projects for JDF and XJDF respectively?
XJDF and JDF get merged as JDF
Versons: 1.7, 2.0
XJDF ISO Path
Should XJDF become an ISO Standard?
Advantages of ISO: It is the iso seal of approval.
Currently we are still too dynamic and the iso process would slow us down significantly.
Which version? If any, then post 2.1.
Discussion of Legal / copyright issues
We definitely need the ability to distribute a specification free of charge to members and non-members of CIP4.