Implementability

=Issues=


 * Ambiguity in written specification
 * Gaps in specifications
 * Localization
 * 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
 * Versions
 * 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

=Opportunities=


 * 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:
 * Can't see how it works
 * Conformance testing?
 * Strict reference implementations
 * Different types of implementations have different kinds of conformancea
 * Usable for testing
 * 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?

=Priorities=


 * guidelines for producing better documentation and for splitting up specifications
 * training?

=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

=Comments=


 * 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?

=Actions=

Priority areas for action:


 * Training
 * Documentation

Other ideas:


 * Write a white paper looking at the issue of "reference implementations"
 * Implementation Communities - look across existing developer networks, see what works etc.