\/<\/p>Specification<\/a>\/<\/p>Changes<\/b> Every change carries its reasons.<\/h1> A proposal that changes a function updates the specification, the schemas and the conformance tests together, so that text, contract and test never diverge.<\/p> Read the specification<\/a>Contribute<\/a> Functions<\/dt>12<\/dd> State machines<\/dt>11<\/dd> Objects<\/dt>21<\/dd> Standards<\/dt>48<\/dd> <\/dl> <\/section> Specification<\/a>Functions<\/a>State machines<\/a>Flows<\/a>Objects<\/a>Participants<\/a>Standards<\/a>Conformance<\/a>Governance<\/a>Changes<\/a>Implementers<\/a>Wire bindings<\/a>Reference scenes<\/a> <\/nav> On this page<\/p>Lineage<\/span><\/li>The record<\/span><\/li>Versions<\/span><\/li>References<\/span><\/li><\/ol><\/nav>The practice this part continues.<\/h2> <\/header>1984 End to end, rough consensus<\/dt>Saltzer, Reed and Clark argued that functions placed in the network can be completely and correctly implemented only with the knowledge of the end systems; RFC 1958 recorded the principle for the Internet\u2019s architecture. The IETF\u2019s working method, summarised in RFC 7282 as \u201crough consensus and running code\u201d, sets the standard for how an open protocol should change. The protocol keeps authority at the site and changes only through open proposals. [1]<\/span><\/sup>[2]<\/span><\/sup>[3]<\/span><\/sup><\/dd> 2013\u20132016 Provenance and reuse<\/dt>The W3C PROV documents (2013) define an interchange model for provenance; the FAIR Guiding Principles (2016) ask that data be findable, accessible, interoperable and reusable. The protocol attaches provenance, uncertainty, quality and correction state to every value, so that reuse never strips the conditions of measurement. [4]<\/span><\/sup>[5]<\/span><\/sup><\/dd> <\/dl><\/section>What a change carries.<\/h2>A proposal that changes a function moves these together, in one change.<\/p> <\/header>Specification text<\/h3>The normative text of the function, revised.<\/p> Function index<\/h3>The machine-readable list of functions, kept in step.<\/p> Schemas<\/h3>The contract schemas the change affects, each with its own schema version.<\/p> Conformance tests<\/h3>The tests that show the change has been implemented as written.<\/p> <\/section>How versions are numbered.<\/h2> <\/header>Protocol version<\/dt>Written obsp\/<major>.<minor>. Until 1.0 a minor version MAY break compatibility; from 1.0 only a major version does.<\/dd> Schema versions<\/dt>Contract schemas carry their own schema version, distinct from the protocol version.<\/dd> <\/dl><\/section>References<\/h2>Sources for the historical and standards statements on this page.<\/p> <\/header>Saltzer, J. H., Reed, D. P., and Clark, D. D. (1984). “End-to-End Arguments in System Design.” ACM Transactions on Computer Systems 2(4). web.mit.edu\/Saltzer\/www\/publications\/endtoend\/endtoend.pdf<\/a><\/li>Carpenter, B., ed. (1996). RFC 1958, “Architectural Principles of the Internet.” IETF. www.rfc-editor.org\/rfc\/rfc1958<\/a><\/li>Resnick, P. (2014). RFC 7282, “On Consensus and Humming in the IETF.” IETF. www.rfc-editor.org\/rfc\/rfc7282<\/a><\/li>W3C (2013). “PROV-Overview: An Overview of the PROV Family of Documents.” W3C Working Group Note, 30 April 2013. www.w3.org\/TR\/prov-overview\/<\/a><\/li>Wilkinson, M. D., et al. (2016). “The FAIR Guiding Principles for scientific data management and stewardship.” Scientific Data 3, 160018. doi.org\/10.1038\/sdata.2016.18<\/a><\/li>Bradner, S. (1997). RFC 2119, “Key words for use in RFCs to Indicate Requirement Levels.” IETF. www.rfc-editor.org\/rfc\/rfc2119<\/a><\/li>Leiba, B. (2017). RFC 8174, “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words.” IETF. www.rfc-editor.org\/rfc\/rfc8174<\/a><\/li><\/ol><\/section><\/main> Read it, test it, propose a change.<\/h2>The Observatory Protocol is an open specification stewarded by the Nexus Consortium. Any party may implement it, and every change is proposed and decided in public.<\/p> Read the specification<\/a>Contribute<\/a> <\/section>
\/<\/p>Changes<\/b> Every change carries its reasons.<\/h1>
A proposal that changes a function updates the specification, the schemas and the conformance tests together, so that text, contract and test never diverge.<\/p> Read the specification<\/a>Contribute<\/a> Functions<\/dt>12<\/dd> State machines<\/dt>11<\/dd> Objects<\/dt>21<\/dd> Standards<\/dt>48<\/dd> <\/dl> <\/section> Specification<\/a>Functions<\/a>State machines<\/a>Flows<\/a>Objects<\/a>Participants<\/a>Standards<\/a>Conformance<\/a>Governance<\/a>Changes<\/a>Implementers<\/a>Wire bindings<\/a>Reference scenes<\/a> <\/nav> On this page<\/p>Lineage<\/span><\/li>The record<\/span><\/li>Versions<\/span><\/li>References<\/span><\/li><\/ol><\/nav>The practice this part continues.<\/h2> <\/header>1984 End to end, rough consensus<\/dt>Saltzer, Reed and Clark argued that functions placed in the network can be completely and correctly implemented only with the knowledge of the end systems; RFC 1958 recorded the principle for the Internet\u2019s architecture. The IETF\u2019s working method, summarised in RFC 7282 as \u201crough consensus and running code\u201d, sets the standard for how an open protocol should change. The protocol keeps authority at the site and changes only through open proposals. [1]<\/span><\/sup>[2]<\/span><\/sup>[3]<\/span><\/sup><\/dd> 2013\u20132016 Provenance and reuse<\/dt>The W3C PROV documents (2013) define an interchange model for provenance; the FAIR Guiding Principles (2016) ask that data be findable, accessible, interoperable and reusable. The protocol attaches provenance, uncertainty, quality and correction state to every value, so that reuse never strips the conditions of measurement. [4]<\/span><\/sup>[5]<\/span><\/sup><\/dd> <\/dl><\/section>What a change carries.<\/h2>A proposal that changes a function moves these together, in one change.<\/p> <\/header>Specification text<\/h3>The normative text of the function, revised.<\/p> Function index<\/h3>The machine-readable list of functions, kept in step.<\/p> Schemas<\/h3>The contract schemas the change affects, each with its own schema version.<\/p> Conformance tests<\/h3>The tests that show the change has been implemented as written.<\/p> <\/section>How versions are numbered.<\/h2> <\/header>Protocol version<\/dt>Written obsp\/<major>.<minor>. Until 1.0 a minor version MAY break compatibility; from 1.0 only a major version does.<\/dd> Schema versions<\/dt>Contract schemas carry their own schema version, distinct from the protocol version.<\/dd> <\/dl><\/section>References<\/h2>Sources for the historical and standards statements on this page.<\/p> <\/header>Saltzer, J. H., Reed, D. P., and Clark, D. D. (1984). “End-to-End Arguments in System Design.” ACM Transactions on Computer Systems 2(4). web.mit.edu\/Saltzer\/www\/publications\/endtoend\/endtoend.pdf<\/a><\/li>Carpenter, B., ed. (1996). RFC 1958, “Architectural Principles of the Internet.” IETF. www.rfc-editor.org\/rfc\/rfc1958<\/a><\/li>Resnick, P. (2014). RFC 7282, “On Consensus and Humming in the IETF.” IETF. www.rfc-editor.org\/rfc\/rfc7282<\/a><\/li>W3C (2013). “PROV-Overview: An Overview of the PROV Family of Documents.” W3C Working Group Note, 30 April 2013. www.w3.org\/TR\/prov-overview\/<\/a><\/li>Wilkinson, M. D., et al. (2016). “The FAIR Guiding Principles for scientific data management and stewardship.” Scientific Data 3, 160018. doi.org\/10.1038\/sdata.2016.18<\/a><\/li>Bradner, S. (1997). RFC 2119, “Key words for use in RFCs to Indicate Requirement Levels.” IETF. www.rfc-editor.org\/rfc\/rfc2119<\/a><\/li>Leiba, B. (2017). RFC 8174, “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words.” IETF. www.rfc-editor.org\/rfc\/rfc8174<\/a><\/li><\/ol><\/section><\/main> Read it, test it, propose a change.<\/h2>The Observatory Protocol is an open specification stewarded by the Nexus Consortium. Any party may implement it, and every change is proposed and decided in public.<\/p> Read the specification<\/a>Contribute<\/a> <\/section>
On this page<\/p>
A proposal that changes a function moves these together, in one change.<\/p> <\/header>
The normative text of the function, revised.<\/p>
The machine-readable list of functions, kept in step.<\/p>
The contract schemas the change affects, each with its own schema version.<\/p>
The tests that show the change has been implemented as written.<\/p> <\/section>How versions are numbered.<\/h2> <\/header>Protocol version<\/dt>Written obsp\/<major>.<minor>. Until 1.0 a minor version MAY break compatibility; from 1.0 only a major version does.<\/dd> Schema versions<\/dt>Contract schemas carry their own schema version, distinct from the protocol version.<\/dd> <\/dl><\/section>References<\/h2>Sources for the historical and standards statements on this page.<\/p> <\/header>Saltzer, J. H., Reed, D. P., and Clark, D. D. (1984). “End-to-End Arguments in System Design.” ACM Transactions on Computer Systems 2(4). web.mit.edu\/Saltzer\/www\/publications\/endtoend\/endtoend.pdf<\/a><\/li>Carpenter, B., ed. (1996). RFC 1958, “Architectural Principles of the Internet.” IETF. www.rfc-editor.org\/rfc\/rfc1958<\/a><\/li>Resnick, P. (2014). RFC 7282, “On Consensus and Humming in the IETF.” IETF. www.rfc-editor.org\/rfc\/rfc7282<\/a><\/li>W3C (2013). “PROV-Overview: An Overview of the PROV Family of Documents.” W3C Working Group Note, 30 April 2013. www.w3.org\/TR\/prov-overview\/<\/a><\/li>Wilkinson, M. D., et al. (2016). “The FAIR Guiding Principles for scientific data management and stewardship.” Scientific Data 3, 160018. doi.org\/10.1038\/sdata.2016.18<\/a><\/li>Bradner, S. (1997). RFC 2119, “Key words for use in RFCs to Indicate Requirement Levels.” IETF. www.rfc-editor.org\/rfc\/rfc2119<\/a><\/li>Leiba, B. (2017). RFC 8174, “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words.” IETF. www.rfc-editor.org\/rfc\/rfc8174<\/a><\/li><\/ol><\/section><\/main> Read it, test it, propose a change.<\/h2>The Observatory Protocol is an open specification stewarded by the Nexus Consortium. Any party may implement it, and every change is proposed and decided in public.<\/p> Read the specification<\/a>Contribute<\/a> <\/section>
Sources for the historical and standards statements on this page.<\/p> <\/header>
The Observatory Protocol is an open specification stewarded by the Nexus Consortium. Any party may implement it, and every change is proposed and decided in public.<\/p> Read the specification<\/a>Contribute<\/a> <\/section>