- Ambiguity in written specification
- Gaps in specifications
- Vocabularies and control lists
- Managing national-level implementations with transnational specifications
- Specs/standards specifying non-international vocabularies (e.g. US-centric etc)
- Over-specifying for communities with a string local context
- Need clearer boundaries between areas of standard that are general and areas that require localization
- Size of documents
- Too much documentation - can lead to more errors and confusion
- Scope of standards too large
- Standardisation boiler plate
- Problems hidden
- Standards not written with implementation experience
- If too based on implementation, risk of being too local
- If not based on implementation, can be hard to implement, have problems
- Lag between standards setting and use context
- Emerging base technologies/standards
- Change in platform ecology
- Backwards compatibility
- Multiple versions
- Access to the spec
- Can't read it? Can't talk to anyone about it? Can't implement it
- Members only business model
- Pay for standards business model
- Documentation aimed at implementation
- Different kinds of implementations may need different kinds of documentation
- Formalisation and structured markup
- Conformance testing, automated testing
- Decoupling conformance testing (open, free) from certification (paid for)
- Decoupling of standardisation and vocabulary
- Reference implementations
- What is a reference implementation?
- Commonly referenced implementation
- Closed source RIs are an issue:
- Conformance testing?
- Strict reference implementations
- Different types of implementations have different kinds of conformancea
- Cut the specs down into speclets - make them modular
- Specification and implementation in parallel
- Communities of implementation
- Training for people involved in standardisation
- Many people getting involved in consortia from companies/organisations have no prior experience
- Orgs like CETIS have experience, could run courses?
- guidelines for producing better documentation and for splitting up specifications
Role of govt
- Some discussion on role of govt in standards and implementability
- Regulatory role of government in markets
- Govt pressure on market to adopt interoperability (e.g. IWBCFF)
- Govt attempts at standardisation (e.g. ISB)
- Purchasing requirements
- Kitemarks and conformance
- Reference implementation is a tricky concept and we have to be clear - e.g. does the RI override the spec?
- Are there really closed-source RIs? (Answer: yes)
- Should be realistic about community of implementers - we know who they are and so should modify our expectations accordingly. E.g. structural engineering specs take years of study to understand.
- Training would be useful-also can produce better tools and techniques to help people engage who aren't standards specialists
- Cutting down on spec docs should be done with caution - easy to lose the context (e.g. what problem it intends to solve)
- Increasingly difficult to get people involved in spec drafting
- Can we use formal ontology to help with spec development and making specs implementable?
Priority areas for action:
- Write a white paper looking at the issue of "reference implementations"
- Implementation Communities - look across existing developer networks, see what works etc.