Sep 4, 2020

This version:

https://oagiscore.atlassian.net/wiki/x/DACzJw

Latest version:

https://oagiscore.atlassian.net/wiki/x/DACzJw

Previous version:

Not applicable.

Editor:

James A. Wilson, OAGi, Jim.Wilson@OAGi.org

Errata:

Not applicable

Abstract

The OAGi Digital Resources Development Process (DRDP) governs the process of producing and maintaining OAGi’s Digital Resources.

Status of This Document

This is the Sep 4, 2020 version of the OAGi Patent Policy.

This document has been approved by the OAGi Policy Board effective Sep 4, 2020 and has been endorsed by the OAGi President as the OAGi Digital Resource Development Process. It is a stable document and may be used as reference material or cited as a normative reference from another document. This policy was produced by the OAGi staff.

Please report errors in this document to Member.Services@OAGi.org. The list of known errors is public.

The English version of this policy is the only normative version.

Table of Contents

1. Overview

The OAGi Digital Resources Development Process (DRDP) governs the process of producing and maintaining OAGi’s Digital Resources.

2. Definitions

The following terms and definitions apply to this document and to the OAGi Patent Policy [PATENT].

• OAGi Member: Any individual or organization that has joined OAGi, as well as any employee or designated representative (e.g., contractor) of such organizations.

• Call for Participation: A communication to OAGi members that invites them to participate in a Working Group.

• Collaborating Digital Resources Body: A Digital Resources body with which OAGi has formal agreement. The form of the agreement could be reciprocal membership, letter-of-intent, memorandum of understanding, etc.

• Digital Resource: Refers to any digital content developed with the intent of assisting companies with implementing electronic connectivity between systems and devices within their own company, and between their company and other companies. Digital Resource includes standards, guidelines, communications tools, project-management tools, implementation tools, and requirements or proposals passed on to a Collaborating Digital Resources Body.

• Draft Revised Digital Resource: A digital resource that was initially produced by the Architecture Committee by copying a Digital Resource for the purposes of updating it.

• Member Submission: One or more documents developed outside of the OAGi Digital Resources Development Process and Information about the documents, provided by the Submitter. See section 7.

• Proposed New Digital Resource: Any digital resource produced by a Working Group that the Working Group delivers to the Architecture Committee with the intent that the Architecture Committee will approve and publish it as a Digital Resource.

• Proposers: One or more OAGi Members who develop a Working Group charter and submit it to the OAGi Architecture Committee.

• Submitter: See section 7.

• WG: Working Group

• Working Group: An OAGi organizational unit that produces Digital Resources.

3. Main Success Scenarios for High-Level Process Definitions

By main success scenario we mean a primary and exception-free process scenario. Greater detail is provided in the process diagrams in sections 4.

3.1 OAGi Creates New Digital Resources

1. Proposers develop a Working Group charter and submit it to the OAGi Staff.

2. The OAGi Staff recommends charter approval and submits it to the OAGi President.

3. The OAGi President approves the charter and communicates approval to the OAGi Staff.

4. The OAGi Staff communications approval to the Proposers.

5. The OAGi Staff issues a Call for Participation.

6. Interested OAGi Members respond to the Call for Participation by affirmatively joining the Working Group.

7. The OAGi Staff convenes the first meeting of the Working Group during which a Working Group Chair, Vice Chair, and other charter-specified roles are selected.

8. The Working Group conducts its work in accordance with the charter.

9. At any point the Working Group has produced a deliverable that it determines is ready to be delivered to the Architecture Committee, it does so via the Architecture Committee. At this point the Architecture Committee has a Proposed New Digital Resource.

10. The Architecture Committee reviews the Proposed New Digital Resource.

11. The Architecture Committee approves the Proposed New Digital Resource in a meeting in which the OAGi Staff participates.

12. The Architecture Committee determines whether or not a public review period is in the best interest of its membership, and if so, conducts one. The OAGi Staff may override a decision by the Architecture Committee to not conduct a public review, in which case OAGi conducts a public review. In the event that the Collaborating Digital Resources Body conducts a public review as part of its process, the OAGi Staff may adjust the process specified in section 3.1 in order to conduct a coordinated public review with the Collaborating Digital Resources Body with the objective of reducing the overall elapsed time to publication.

13. The Architecture Committee publishes the Proposed New Digital Resource as a Digital Resource.

3.2. OAGi Updates Existing Digital Resource

1. One or more OAGi Members (Proposers) delivers a written proposal to change an existing Digital Resource to the Architecture Committee.

2. The Architecture Committee reviews the proposal.

3. The Architecture Committee approves the proposal in a meeting in which the OAGi Staff participates. The OAGi Staff may determine that such an update should be developed in the context of a WG, effectively following the process specified in section 3.1, obviating the remaining steps in this section.

4. The Architecture Committee updates the applicable Draft Revised Digital Resource.

5. The Architecture Committee publishes the Draft Revised Digital Resource as a Digital Resource.

3.3. OAGi Maintains a Digital Resource

See section 5.

3.4. OAGi Produces and Delivers Digital Resources to Collaborating Digital Resources Bodies

1. OAGi follows either process 3.1 or 3.2 as appropriate.

2. OAGi Staff delivers one or more Digital Resources to a Collaborating Digital Resources Body. (The OAGi Staff may accomplish this task through a liaison to the Collaborating Digital Resources Body designated by the OAGi Staff.)

3. OAGi Staff, in consultation with the Architecture Committee, monitors the progress of the delivered Digital Resource through the collaborating Digital Resources body and updates the Digital Resource's online publication description. (For example, if the Digital Resource has been incorporated in a published content by the collaborating Digital Resources body, then that should be noted online and perhaps the Digital Resource in the context of an OAGi resource perhaps should be deprecated in favor of the published content by the collaborating Digital Resources body.

4. "OAGi Creates New Digital Resource" Process Diagrams

5. Producing Derived and Maintaining Existing Digital Resources

Some Digital Resources are derived from other resources or require ongoing maintenance. Examples include, but are not limited to code lists, controlled vocabularies, glossaries, data dictionaries, and OAGIS-profile resources. By default, each existing Digital Resource is subject to the process specified in section 3.2. The OAGi Staff shall explicitly designate Digital Resources as qualifying for derivation or maintenance and therefore being subject to the following process:

1. The OAGi Staff explicitly designates a Digital Resource as derived or maintained.

2. The Architecture Committee shall develop a derivation or maintenance process, which shall include approval and publication.

6. Delivering Digital Resources to Collaborating Digital Resources Bodies

Follow the "OAGi Creates New Digital Resources" with the understanding that "Proposed Digital Resource" may not be for publication, but for delivery to a collaborating Digital Resources body (see the last activity "Publish Proposed Digital Resource as a Digital Resource"), or both.

7. Member Submission Process

The Member Submission process allows OAGi Members to propose technology or other ideas to the OAGi Staff for consideration by a Working Group. After a OAGi Staff review, he/she MAY post the material in the associated Working Group's wiki space. The formal process affords OAGi Members a record of their contribution and gives them a mechanism for disclosing the details of the transaction with the Working Group (including IPR claims).

A Member Submission consists of:

• One or more documents developed outside of the OAGi Digital Resources Development Process, and

• Information about the documents, provided by the Submitter.

One or more OAGi Members (called the "Submitter(s)") MAY participate in a Member Submission. Only OAGi Members MAY be listed as Submitter(s).

The Submission process consists of the following steps:

1. One of the Submitter(s) sends a request to the OAGi Staff to acknowledge the Submission request. The OAGi Staff and Submitter(s) communicate to ensure that the Member Submission is complete.

2. After OAGi Staff review, the OAGi Staff MUST either acknowledge or reject the Submission request.

• If acknowledged, the Working Group MUST publish the Member Submission in the Working Group wiki space.

• If rejected, the Submitter(s) MAY appeal to either the OAGi President or the OAGi Policy Board.

Note: To avoid confusion about the Member Submission process, please note that:

• The Submission process is not a means by which OAGi Members ask for "ratification" of these documents as Digital Resources.

• There is no requirement or guarantee that technology which is part of an acknowledged Submission request will receive further consideration by OAGi (e.g., by a Working Group).

Posting of a Member Submission to a Working Group wiki space does not imply endorsement by OAGi staff, OAGi Members, or Working Group. The acknowledgment of a Submission request does not imply that any action will be taken by OAGi. It merely records publicly that the Submission request has been made by the Submitter. A Member Submission MUST NOT be referred to as "work in progress" of OAGi.

7.1 Submitter Rights and Obligations

When more than one Member jointly participates in a Submission request, only one Member formally sends in the request. That Member MUST copy each of the Primary Contacts of the other participating OAGi Members, and each of those Primary Contacts MUST confirm (by email to the OAGi Staff) their participation in the Submission request.

At any time prior to acknowledgment, any Submitter MAY withdraw support for a Submission request (described in "How to send a Submission request"). A Submission request is "withdrawn" when no Submitter(s) support it. The OAGi Staff MUST NOT make statements about withdrawn Submission requests.

Prior to acknowledgment, the Submitter(s) MUST NOT, under any circumstances, refer to a document as "submitted to OAGi" or "under consideration by OAGi" or any similar phrase either in public or OAGi Member communication. The Submitter(s) MUST NOT imply in public or OAGi Member communication that OAGi is working (with the Submitter(s)) on the material in the Member Submission. The Submitter(s) MAY publish the documents in the Member Submission prior to acknowledgment (without reference to the Submission request).

After acknowledgment, the Submitter(s) MUST NOT, under any circumstances, imply OAGi investment in the Member Submission until, and unless, the material has been adopted as a deliverable of an OAGi Working Group

7.1.1 Scope of Member Submissions

When a technology overlaps in scope with the work of a chartered Working Group, OAGi Members should participate in the Working Group and contribute the technology to the group's process. The Working Group MAY incorporate the contributed technology into its deliverables.

On the other hand, while OAGi Members are in the early stages of developing a charter, OAGi Members should use the Submission process to build consensus around concrete proposals for new work.

Members should not submit materials covering topics well outside the scope of OAGi's mission.

7.1.2 Information Required in a Submission Request

The Submitter(s) and any other authors of the submitted material MUST agree that, if the request is acknowledged, the documents in the Member Submission will be subject to the OAGi Document License [LICENSE] and will include a reference to it. The Submitter(s) MAY hold the copyright for the documents in a Member Submission.

The request MUST satisfy the Member Submission licensing commitments of section 3.3 of the OAGi Patent Policy [PATENT].

The Submitter(s) MUST include the following information:

• The list of all submitting Members.

• Position statements from all submitting Members (gathered by the Submitter). All position statements MUST appear in a separate document.

• Complete electronic copies of any documents submitted for consideration (e.g., a technical specification, a position paper, etc.) If the Submission request is acknowledged, these documents will be posted by the OAGi Staff to the associated Working Group's wiki page. Submitters MAY hold the copyright for the material contained in these documents, but when posted by OAGi, these documents MUST be subject to the provisions of the OAGi Document License [LICENSE].

The request MUST also answer the following questions.

• What proprietary technology is required to implement the areas addressed by the request, and what terms are associated with its use? Again, many answers are possible, but the specific answer will affect the OAGi Staff's decision.

• What resources, if any, does the Submitter intend to make available if the OAGi Staff acknowledges the Submission request and takes action on it?

• What action would the Submitter like OAGi to take if the Submission request is acknowledged?

• What mechanisms are there to make changes to the specification being submitted? This includes, but is not limited to, stating where change control will reside if the request is acknowledged.

7.2 Submitter Rights and Obligations

The documents in a Member Submission MUST fulfill the requirements specified by the OAGi Staff (as of this writing requirements are not specified).

The OAGi Staff sends a validation notice to the Submitter(s) once the he/she has reviewed a Submission request and judged it complete and correct.

Prior to a decision to acknowledge or reject the request, the request is OAGi staff-only, and the OAGi staff MUST hold it in the strictest confidentiality. In particular, the OAGi staff MUST NOT comment to the media about the Submission request.

7.3 Acknowledgment of a Submission Request

The OAGi Staff acknowledges a Submission request by sending an announcement to the OAGi Policy Board. Though the announcement MAY be made at any time, the Submitter(s) can expect an announcement within 14 days after the validation notice. The OAGi Staff MUST keep the Submitter(s) informed of when an announcement is likely to be made.

Once a Submission request has been acknowledged, the OAGi Staff MUST:

• Publish the Member Submission.

• Publish OAGi Staff comments about the Submission request.

If the Submitter(s) wishes to modify a document published as the result of acknowledgment, the Submitter(s) MUST start the Submission process from the beginning, even just to correct editorial changes.

7.4 Rejection of a Submission Request

The OAGi Staff MAY reject a Submission request for a variety of reasons, including any of the following:

• The ideas expressed in the request overlap in scope with the work of a chartered Working Group, and acknowledgment might jeopardize the progress of the group.

• The IPR statement made by the Submitter(s) is inconsistent with the OAGi's Patent Policy [OAGi Digital Resource-Development Process#PATENT], Document License [OAGi Digital Resource-Development Process#LICENSE], or other IPR policies.

• The ideas expressed in the request are poor or run counter to OAGi's mission.

• The ideas expressed in the request lie well outside the scope of OAGi's mission.

In case of a rejection, the OAGi Staff MUST inform the OAGi Policy Board, the Submitter(s), and Primary Contacts of the Submitter(s). The OAGi Staff MUST provide rationale about the rejection. Other than to the aforementioned parties, the OAGi Staff MUST NOT make statements about why a Submission request was rejected.

The Primary Contacts associated with the Submitters(s) MAY appeal the rejection to the OAGi Policy Board. At the time an appeal is made, the OAGi President will establish a process for such appeals that ensures the appropriate level of confidentiality.

8. Definition of Normative, Optional and Informative

For purposes of this definition, the normative portions of the Digital Resource shall be deemed to include only architectural and interoperability requirements. Optional features in the RFC 2119 [OAGi Digital Resource-Development Process#KEYWORDS] sense are considered normative unless they are specifically identified as informative. Implementation examples or any other material that merely illustrate the requirements of the Digital Resource are informative, rather than normative.

Appendix A: Fast-Track Digital Resource-Development Exception

Activity duration (e.g., member review duration) specified in this document may be reduced according to the following process:

1. A Working Group members proposes a reduction in one or more activity durations.

2. The Working Group chair conducts a vote and the vote result is that all Working Group members have voted and each vote is affirmative.

3. The Working Group chair submits the approved change to the OAGi Staff.

4. The OAGi Staff may suggest adjustments.

   1. If the OAGi Staff suggests adjustments, the Working Group chair may take the changes back to the Working Group for a vote (step 2) or reject the adjustments.

5. The OAGi Staff will present the proposed changes to the OAGi Policy Board.

6. The OAGi Policy Board will approve or reject the proposal. In any case, the OAGi Staff will report the outcome to the Working Group chair.

References

[KEYWORDS]

Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. The Internet Society, March 1997. This RFC is available by FTP at ftp://ftp.rfc-editor.org/in-notes/rfc2119.txt.

[PATENT]

OAGi Patent Policy, J. Wilson, Editor. OAGi, Sep 4, 2020. The latest version of this document is https://oagiscore.atlassian.net/wiki/x/AYDfJw.

[LICENSE]

OAGi Document License, J. Wilson, Editor. OAGi, Sep 4, 2020. The latest version of this document is https://oagiscore.atlassian.net/wiki/x/ToDMyQ.

Acknowledgments

Significant portions of this document is derived from the World Wide Web Consortium Process Document available at https://www.w3.org/2019/Process-20190301/. Various license requirements apply, which are met by including the following statement, with associated links, from the W3C:

W3C liability, trademark, document use and software licensing rules apply.