1.0 Abstract

The OGCprovides a collaborative, consensus process for developing and approving open, international standards for the geospatial domain. “International standards”^[1] are those adopted by an international standardizing/standards organization and made available to the public. Specifically, an OGC standard is:

A document, established by consensus and approved by the OGC Membership, that provides, for common and repeated use, rules, guidelines or characteristics for activities or their results, aimed at the achievement of the optimum degree of order in a given context.

To guide an open standards development and approval process, a member approved Policies and Procedures is required.

This document describes the OGC Technical Committee (TC) policies and procedures (P&P).The TC has been granted authority to operate by the OGC Bylaws.  The TC is composed of individuals representing organizations that are duly recognized members in good standing of the OGC.  The Technical Committee Chair (TCC - see Section 3.2) facilitates the TC process.

The TC P&P:

• Documents all TC voting processes and procedures;
• Documents the formation, scope and processes required for TC subgroup and committee activities;
• Documents the processes and procedures for submitting, reviewing, and approving a new standards using the Request for Comment procedures; and
• Documents the process for revisions to adopted OGC^® standards.

As the needs and purpose of the TC change, these policies and procedures changes are approved by an electronic vote of the Voting Members of OGC TC or by recommendation of the OGC Planning Committee.

The OGC Technical Committee provides an open, collaborative forum for professional discussion related to the consensus development and/or evaluation, approval, and revision of OGC international standards. The primary use of approved OGC standards is to provide the ability to build and deploy interoperable geospatial solutions in the larger Information Technology (IT) domain.

The OGC Principles of Conduct govern personal and public interactions in any TC activity.

2.0 What is a Consortium?

A broad definition of a consortium is: a combination or group of organizations formed to undertake a common objective that is beyond the resources or capabilities of any single organization. The OGC was formed to provide a collaborative, consensus forum for the discussion and resolution of interoperability issues in the geospatial domain. The work of the consortium is based on volunteerism.

More specifically in the standards area, a consortium has the following characteristics:

• May or may not have been accredited by any national or global entity;
• Is usually (but not always) international in membership and objectives;
• May have a very narrow or a broad mission (but still generally within a single focus area);
• Has as its primary goal(s) the creation and/or promotion of international standards (most commonly in the IT area);
• Creates what would be acknowledged to be “open” standards made available on Reasonable and Non-Discriminatory (RAND) terms; and
• May engage in additional activities, such as the creation of white papers, training and certification, but which rarely becomes a “trade association” in the non-tax sense.

The OGC is defined as a Voluntary Consensus Standards Organization^[2].

3.0 Purpose and Composition of the Technical Committee

The OGC Corporate bylaws state that the OGC Technical Committee (TC) shall be responsible for developing standards^[3] through a cooperative consensus process involving the Members. The bylaws provide authority to:

• Design and maintain an Abstract Specificationfor a computing technology independent application environment for interoperable geo-processing and geospatial data products;
• Use the Abstract Specification as a reference to solicit, propose, review, recommend revisions to, and recommend adoption of standards, also known as OGC standards;
• Provide the forum for discussing, reviewing, and adopting changes to existing approved OGC standards;
• Accept, discuss, review, and recommend action on documents developed in the OGC Interoperability Programand then submitted to the TC;
• Discuss, review, and recommend action with regard to standards and relevant standards developed in other standards organizations; and
• Discuss and agree on requirements, use cases, and change requests to existing OGC standards.

Above all, the Technical Committee provides an open forum for professional discussion of issues and items related to the consensus development and/or evaluation and approval of candidate standards and revisions to existing adopted OGC standards that provide the ability to build and deploy interoperable geospatial solutions in the larger IT domain. The OGC Principles of Conduct^[4] govern personal and public interactions in any TC activity.

The structure of the TC is discussed in Section 4 of this document. Section 5 describes the policies and procedures for the submission, evaluation, and potential recommendation for adoption of a new or revised standard.

3.1 Composition of the TC

The OGC Bylaws provide the enabling authority for the OGC Technical Committee. The TC has the following composition:

• The Technical Committee Chair (appointed by the OGC President and approved by the OGC Board of Directors (BOD));
• Representatives of all member organizations of the OGC; and
• Other individuals deemed appropriate by the BOD or Planning Committee.

3.2 Role of the Technical Committee Chair (TCC)

The TCC is responsible for facilitating the progress and work of the Technical Committee. The TCC is a post held by appointment of the OGC President, to lead the activities of the TC. The TCC is an unbiased member of the TC, and therefore does not vote on Items and Issues except as noted below. The TCC shall ensure the following:

• Note is taken of TC Members, Voting TC Members, and their substitutes and proxies at each meeting;
• Minutes are kept of TC meetings, and distributed by OGC Communication as soon as is practical after the meeting;
• TC meetings are announced with appropriate notice (no less than four months) and that a master schedule is initially published on the OGC website at least 8 weeks prior to each meeting;
• TC meetings are facilitated in general;
• A file of TC meeting minutes and all other distributed materials is kept;
• All electronic mail discussions are kept on file;
• The PC and BOD are kept appraised of the current business of the TC;
• TC resolutions for recommendation to the PC are brought to the attention of the PC;
• The various actions for RFCs are issued and processed in a timely, orderly manner; and
• In the event of a tie vote on any given Item or Issue for which a simple majority vote is required, the TCC has the right to cast the deciding vote.

3.3 Clarifications with respect to the composition of the TC.

Although one or more individuals may represent each member organization of the OGC at TC meetings, only OGC Member organizations with TC voting rights (Strategic, Principal, and Technical Committee Members) can vote on any items or issues related to the adoption of an OGC standard, approval of membership of the OAB, the TC Policies and Procedures, or the Standards Baseline. For these votes, only one individual may vote on behalf of each such Member organization. There is no limit to the number of TC members that may represent each OGC member organization at TC meetings.  However, the TCC may limit the number of attendees (on a maximum-per-organization basis) for reasons of meeting space or other operational considerations.

The TCC shall have the authority to nominate and recommend non-OGC organizations to the BOD members for consideration as voting members of the TC for appointment by the BOD.

4.0 Structure of the Technical Committee

The TC is the primary group where OGC standards are developed, discussed, approved, and maintained. The TC members are responsible for the development and maintenance of all standards and related technical documents. The TC membership includes Voting TC Members, non-voting TC Members, and Invited Guests.

The Technical Committee is comprised of four primary subgroups: the OGC Architecture Board, the OGC Naming Authority, Working Groups (WG), and Subcommittees (SC) to:

• Evaluate and provide guidance on architecture issues;
• Carry out the development of new proposals^[5];
• Evaluation of proposals; and
• Provide a forum for the discussion and documentation of requirements for interoperability.

WGs will be formed, carry out their work, and when their work is completed be dissolved. Working Group Policies and Procedures are defined in the section 7.0.

4.1 OGC Architecture Board (OAB)

The mission of the OAB is to provide a forum within which Consortium wide standards architecture issues can be discussed and deliberated with the intent of providing guidance and recommendations to the TC and the PC on these issues. The OAB is a sub-committee of the TC. There is a separate OAB Policies and Procedures

4.2 OGC Naming Authority (OGC-NA)

The OGC Naming Authority (OGC-NA) controls the assignment of OGC Names to resources of interest in geographic information infrastructures. In the terminology defined in ISO 19135, OGC-NA is the Control Body for the register of OGC Names. This document describes the framework of documents, registers and other resources required for OGC-NA to execute that role. There are separate OGC-NA Policies and Procedures.

4.3 Subcommittee (SC) of the TC

A standing group (organizationally, a subgroup of the TC) of individuals composed of members of the TC and Invited Guests, with a mission to provide recommendations to the TC in some general area. A Subcommittee does not generate a standard nor do they work on a standard.

SCs have Voting TC Member-only voting. As with all OGC groups, each Voting TC Member has only one vote per SC. SCs are long-standing entities with general portfolios or mission. OGC staff can chair TC SCs. Any OGC member can attend a SC meeting and participate.

4.4 Working Groups (WGs)

A group (organizationally, a subgroup of the TC) of individuals composed of members of the TC and invited guests, with the specific intent of solving some particular interoperability problem or problems in a particular technology domain for recommendation to the TC. A Group is not a subcommittee as outlined by the Bylaws of the OGC.

There are two types of Working Groups in the TC: Domain Working Groups (DWGs) and Standards Working Groups (SWGs). The reason that there are two different type of Working Groups is due to the OGC Intellectual Property Policy. The OGC IP Policy can be downloaded from http://www.opengeospatial.org/ogc/policies.

4.4.1 Domain Working Group

A group (organizationally, a subgroup of the TC – Section 7.5) of individuals composed of members of the TC and invited guests, with the specific intent of discussing and/or solving some particular problem or problems in a particular domain or technology arena for recommendation to the TC. Key functions of the Domain Working Group (DWG) are to:

• Have a formal approved charter that defines the DWGs Scope of Work and estimated timeline for completion of the work;
• Provide a forum for discussion and documentation of interoperability requirements for a given information or user community;
• Provide a forum to discuss and recommend document actions related to Interoperability Program Reports;
• Develop Change Requests Proposals (CRPs) for existing OGC standards;
• Develop Engineering Reports with the intent seeking approval by the TC for release of these documents as OGC White Papers, Discussion Papers or Best Practices Papers;
• Informational presentations and discussions about the market use of adopted OGC standards.;
• Have all-member voting policies (unless otherwise stated); and
• Have missions and goals defined by the TC.

A DWG Does Not work on RFC submissions, candidate standards, or revisions to existing OGC standards. However, a DWG can develop change requests as document interoperability requirements that can then be submitted as work items to a SWG.

By default, a DWG will allow public collaboration, such as in teleconference, email discussions, or a public twiki. A DWG has the option to make a motion to the TC to remove public participation in the DWG.

4.4.2 Standards Working Group (SWG)

A group (organizationally, a subgroup of the TC) of individuals composed of members of the TC and invited guests with the specific intent of working on a candidate standard prior to approval as an OGC standard or on making revisions to an existing OGC standard. Please see section 7.7 for details on the policies and procedures for SWGs. The following is a general overview.

Specific work items for a SWG could be:

• Have a formal approved charter that defines the SWGs Scope of Work and estimated timeline for completion of the work;
• Develop a new candidate standard in preparation of that document as an RFC submission.
• Process a new RFC submission candidate standard once approved by the OAB;
• Consider official Change Request Proposals to an existing OGC standard and make changes to the standard as necessary: from this perspective, a SWG does all the work that was formerly performed by a Revision Working Group;
• Approve a candidate standard for public comment;
• To vote on any changes to a candidate standard or to an existing OGC standard; and/or
• Make recommendations to the entire TC once a document is ready for a formal adoption vote;

Voting is limited to those Members who are either 1.) Charter Members of the SWG or 2.) have formally opted into the SWG and have waited the mandatory 30-day waiting period.

Unless the SWG voting members decide otherwise, SWGs are dissolved once they have completed their work as described in their charter.

5.0 Meetings of the Technical Committee

This section describes the Policies and Procedures for meetings of the OGC Technical Committee.

5.1 Meetings of the TC

Technical Committee meetings shall be conducted under the general guidance of Robert’s Rules of Order^[6] (RONR). Meetings shall be facilitated by the TCC or other appointed representative(s) of the OGC. The planning goal is to have four meetings per year. The number of meetings per year can be changed by a vote of the TC and the PC.

TC meeting dates and locations will be announced as far in advance as possible but no less than four months in advance of the meeting. Announcements will be through formal OGC Communication. All recommendations, summary notes, presentations, and so forth shall be posted to the OGC Member Portal. 

5.2 Attendance at TC Meetings

Only members of the OGC, Invited Speakers, and Invited Guests are welcome at TC meetings. Any TC member may send another representative of his or her organization as a substitute to a TC meeting (please note paragraph 6.2). Subgroups may only meet by being formally scheduled by the TCC or designee during the course of regularly scheduled TC meetings (subgroups cannot have alternative meetings that overlap temporally with the TC Meeting without approval of the TCC or PC).

5.3 Policy for Invited Guests

From time to time, OGC staff or an OGC member may wish to invite one or more individuals from organizations who are not OGC Members to attend an OGC TC meeting. Reasons for invitations may be to provide technical input, speak (see Policy for Invited Speakers below), or meet with OGC members and/or staff on items and issues germane to the work of the OGC.

Invited Guests (representatives of organizations that are not members of the TC) may actively participate in an OGC meeting at the sole discretion of the TCC. That is, in the interests of ensuring the efficient operation of any meeting, the TCC may limit or eliminate the opportunity of any invited guest to participate in discussion at any meeting.

All Invited Guest invitations and registration must be coordinated with the TCC and the OGC staff responsible for meeting logistics. The steps are very similar to those for Invited Speakers.

• OGC staff or the DWG/SWG Chair provides a formal invitation to the individual with a cc to the TCC and the TC meeting support staff.
• The TCC approves the invitation.
• OGC provides the invited guest with a registration code.
• The invited guest must register with the provided guest registration code.
• Invited guests may or may not have to sign a non-disclosure agreement (NDA). For special meetings held in parallel with the OGC TC meetings, such as an OGC Interoperability Day or a Standards Coordination meeting, NDAs are not required.

The Invited Guest may or may not have to pay a meeting registration fee. OGC staff will work with the members to determine the fee structure for Invited Guests for any given TC meeting.

5.4 Policy for Invited Speakers

From time to time, OGC staff or Members wish to invite an individual from a non-Member organization to speak at an OGC Working Group meeting or Plenary session. Any invited speaker may attend the TC meetings for the day on which they are speaking without having to pay the TC meeting fee. The process is as follows.

• The DWG/SWG Chair provides a formal invitation to the individual with a cc to the TCC and the TC meeting support staff. The formal invitation may be via email.
• The TCC approves the invitation.
• The OGC provides the invited speaker with a speaker registration code.
• The invited speaker must register with the provided speaker registration code.

If the invited speaker wishes to spend more time at the TC meetings beyond the day on which they are speaking, they will need to pay the required TC meeting fee. For the day the invited speaker is attending, they are free to partake of any refreshments but will need to pay for their own lunch or any related OGC social event they wish to attend on that day. Finally, the speaker may need to sign the standard OGC Non-Disclosure Agreement (NDA).

5.5 Agenda and Schedule of a TC Meeting

At least eight weeks before a TC meeting, a draft master schedule for that TC meeting will be posted to the public OGC web site. The agenda is managed solely by the TCC or designee, and will be modified prior to the meeting as appropriate. One to two weeks prior to a meeting, the TCC shall, via email, provide the TC a summary document of keys actions and presentations.

The WG Chairs shall provide the TCC or designee meeting date and time requests at least 4 weeks before the actual TC meeting. The earlier the better!

Each WG Chair shall email an agenda to OGC members at least three weeks before the meeting. Due to schedule conflicts, WG Chairs that fail to provide a proposed agenda by one week before the meeting may forfeit the right to meet during the course of regularly scheduled TC meeting times. However, the Chairs of a WG that do not provide an agenda can elect to have an ad-hoc meeting during the off-hours (such as a breakfast or after dinner session).

5.6 Policies related to the recording of an OGC Meeting

If there is a GoToMeeting (or similar technology) session assigned for a specific OGC Working Group, TC Plenary, or PC meeting, there is the option to record the session for later use by OGC staff and OGC members. Guidance for such recording is as follows.

• The members attending the meeting need to be notified that the meeting is being recorded. If there are objections, then the meeting shall not be recorded.
• The recording shall remain members-only and shall not be available to the public. The exception is for open meetings in which the public is invited to attend.
• All recordings shall be uploaded to the appropriate meeting folder on the OGC portal.

6.0 Voting During and Between TC Meetings

The following policies address voting during and between TC meetings. One of the primary functions of the TC is to vote on a variety of actions, items, and issues. Votes can be for any purpose pertaining to the format and content of the Abstract Specification, Candidate standards, OGC standards, Discussion Papers, approval of the slate of nominations for the OGC Architecture Board, Best Practices Documents, Policies and Procedures of the TC, and for other purposes consistent with the purpose of the TC as described in these Policies and Procedures. TC will make recommendations to the PC concerning adoption of a candidate standard, changes to a standard, or changes in process.

6.1 Quorum for a TC Meeting

The quorum for any meeting of the Technical Committee Members shall be 1/3 of the total Voting membership as comprised by the Strategic, Principal, Technical, and Technical Aggregate Members. If there is quorum, then a simple majority of the Voting TC Members present at a meeting shall constitute a positive vote for all TC Items and Issues. A roll call will be held at the beginning of each Plenary to insure a quorum is present.

The only exception for this Quorum rule is for a vote to issue an electronic vote for adoption of a new or revised version of a candidate standard. In this case, a simple majority vote of those TC Voting members present constitutes a successful vote.

6.2 Substitute Voters

Voting TC members may send substitutes to TC meetings but these substitutes may only vote if they have submitted a written proxy statement to the TCC or designee (see section 6.7) by the Voting TC Member of his or her organization. A paper (postal or facsimile) vote by a Voting TC Member may also be accepted at a TC meeting.^[7] Please note that these proxies are only required for voting in a TC Plenary. They are not required for voting in a TC Subcommittee or WG.

6.3 Three Week Rule

For votes that require documentation, such as adoption of particular documents as standards or documents to be released for public comment, one third of the Voting TC members in attendance may invoke the requirement that documentation supporting the vote must be available three weeks prior to the vote. The TC may override the 3-week rule by a 2/3-majority vote of Voting TC members in attendance at a meeting.

The three-week rule clause ensures that Voting TC members have adequate time to read, distribute and gather comments on documents before voting on the document at the following TC meeting.

6.4 Voting at TC Meetings

Many votes happen during a face-to-face TC Meeting. Votes can occur in a TC Plenary or in any sub-group meeting. Votes may be related to document actions, recommendations for staff action, formation of new sub-groups, approval of WG charters, and so forth. This section provides guidance on the policies and procedures related to votes at TC meetings.

6.4.1 Votes that can occur at a TC DWG Face to Face Meeting

Any number of votes can occur at a TC DWG meeting. No prior notice is required to have a vote at a DWG meeting during a TC. Any member representative attending a DWG may vote. However, only one member representative from a member organization may vote in a DWG. Any member representative attending a DWG can frame a motion.

The votes that may occur at a DWG are:

• Move to release an Engineering Report as a Discussion Paper;
• Move to initiate an electronic vote to release an Engineering Report or other OGC document as a Best Practices document;
• Move to elevate a Discussion Paper to a Best Practices document;
• Move to recommend to the TC a change in policy or procedure;
• Move to accept or revise a DWG charter;
• Move to dissolve a DWG; and
• Move to modify the charter of a DWG.

All of these motions of the DWG are recommendations to the full TC.

6.4.2 Votes that can occur in a TC Plenary

Many votes usually occur in the Opening or Closing TC Plenary. The following is a matrix of possible votes and who can vote.

For “Any Member” votes, only one member representative from a given Member Organization may vote.

6.4.3 Form of a Document Motion in a SC or WG

All SC or WG document votes, except for Best Practices and standards adoption votes shall have the following language:

The <Name of the SC or WG> recommends that the TC approve the release of <OGC Document number and Name> as an OGC <White, Discussion, or Engineering> Document.

Often the following clause is added:

“Pending any final edits to the document.”

Best Practice and standards adoption votes shall have the following language:

The <Name of the SC or WG> recommends that the TC approve an electronic vote for  releasing <OGC Document number and Name> as a <OGC Best Practice or Adopted Standard>.

6.4.4 Proxy Format and Content

Not every OGC TC Voting member can attend every TC Plenary. Therefore, the OGC maintains a proxy process. The official TC Voting representative for an organization can assign their proxy to another full-time employee of their organization, to another individual from another TC Member voting organization, or to the TCC.

Proxies can be assigned electronically and are also provided for each meeting and are sent to the Voting members via email as well as being posted to the TC meeting folder for which the proxy will be valid.

Please complete the proxy and notify the TCC or bring the signed proxy to the TC meeting and give it to the TCC. The TCC shall send reminders to the Voting Members prior to the meetings.

6.5 TC Electronic Voting

At any time, the TCC, the TC or a subgroup of the TC may recommend starting an electronic vote. Initiation of electronic votes may be brought by motion and second at a TC plenary meeting, a WG meeting, or by direct action of the TCC. Please refer to Table 1 for what membership level is allowed to vote for any particular vote. The following rules are for official OGC votes related to:

• Adoption of an OGC Abstract and Implementation standards;
• Adoption of a revision to an existing OGC Abstract or Implementation standard;
• Adoption of a OGC Policies and Procedures;
• Approval of an OGC Best Practice;
• Election of of representatives to the OGC Architecture Board; and
• Approval of a Standards Working Group Charter and a new standards work activity.

6.5.1 Duration

Unless otherwise stated by the TCC or designee the normal deadline for response to an electronic vote shall be 45 days from the date of issuance of the electronic vote. There are no extensions for NO votes or insufficient votes (see Sufficiency). The start and end dates for any given vote are set by OGC staff and are posted with the ballot and announced.

6.5.2 Continuity

Except for the following reasons, an electronic vote shall remain open for the duration as stated in Duration (6.5.1):

• A WG withdraws the motion to approve a candidate standard (see Withdrawal); or
• The TCC, the OAB, or the WG identifies a procedural error and requests the vote be stopped.

6.5.3 Eligibility

All Voting TC Members^[8] in good standing at any time during the electronic vote can participate in electronic voting, whether or not they have participated in any preceding TC meeting or electronic vote. All such Members are referred to as “Eligible Voters”. Each Eligible Voter shall have one vote.

6.5.4 Number of Eligible Voters

For each electronic vote, the number of Eligible Voters shall be determined as of the date of the start of the electronic vote. The number of Eligible Voters for a given vote shall be determined by OGC staff and shall be posted with the ballot and announced. This number shall not change for an active vote regardless of whether members gain or lose voting eligibility.

6.5.5 Allowable Votes

The Voting Member may vote Yes, No, or Abstain. Abstain counts toward Sufficiency. Comments may be provided with any vote. Any Eligible Voter may change their vote during the voting period but not after the vote is closed.

6.5.6 Sufficiency

For all votes on any OGC document or OGC policy, sufficiency requires 33% of the Eligible voters to vote. Further, 15% of the total number of Eligible voters must vote YES.

If during the vote there is a new TC Voting Member, that Member may vote but does not change the Sufficiency rule.

6.5.7 Approval^[9]

In addition to Sufficiency thresholds, for documents that are official OGC positions, such as a standard, an OGC Best Practice, or an OGC policy, a motion passes (is approved) if the number of YES votes is twice the number of NO votes. All other documents pass with a simple majority

6.5.8 Comments

Any Eligible Voter that votes may submit a written comment. If an Eligible Voter votes NO, then that Voter shall also submit a written comment explaining their reason for voting NO. If this is a standards adoption vote, then the SWG shall respond in writing to all comments within 30 days of the completion of the vote. If this is a not an adoption vote, then the appropriate TC sub-group shall respond to the comments. The written response to comments shall be in an OGC document and made available to the OGC Membership. If a motion is withdrawn (See Withdrawal) then no response to comments is required.

6.5.9 Withdrawal

A motion may only be withdrawn by the Working Group^[10] that made the original motion. The WG shall have a formal documented vote to withdraw a motion. The reasons for withdrawing a motion are not constrained. The WG shall communicate to the TCC the request to withdraw a motion.  The TCC shall then communicate the decision to withdraw a motion to the entire Membership.

6.5.10 Restarting a vote

The following procedures shall be followed for those cases in which a revote is required.

• If a WG withdrew a motion and there is no content change to the document, the WG can at any time request the TCC initiate new vote.
• If a WG withdrew a motion and the content of the document is changed, then the WG needs to restart the approval process (in the case of a RFC: OAB review, public comment, vote).
• If the vote was stopped for procedural problem(s), fix the problem(s), and initiate a new vote.
• If failure to approve the motion (See Approval and Sufficiency), then the appropriate OGC group needs to address all comments, revise the document and restart the RFC approval process with an OAB review, public comment, final edits to the document and a new adoption vote).

6.5.11 Multi-part Documents

OGC standards documents are often broken into parts along modular lines. Adoption votes for such multi-part documents must either be sequential and not overlapping in terms of start and stop dates or in parallel with the same start and stop dates for the vote.

If the votes are in parallel and if a part fails, then any part containing a module dependent upon a module in the failed part also fails. If the vote is sequential, any part containing a module dependent upon a module in a previously failed part cannot be voted until the failed part is re-voted and approved or the dependency is removed.

6.5.12 Visibility

The following rules relate to transparency of the voting process.

• During and after a vote, individual votes and comments are visible to any OGC member during and after the voting period.
• After the vote is complete, the public only sees the vote result and does not see how an Eligible Voter voted or commented.
• The WG can vote to make public the comments and WG responses to the comments -  but shall not provide the name of the Voter who made a given comment.

6.5.13 Assuming Successful TC vote, what next?

Once the electronic vote completes and assuming a successful TC vote, the following must occur:

• The TCC shall announce the results of the vote.
• If there are any comments, the submission team or SWG shall respond to all comments submitted during the voting period. The responses to the comments shall be documented in an OGC document that is then posted to pending.
• The TCC shall make a recommendation to the Planning Committee requesting approval of the motion from the Technical Committee. The PC shall have two weeks to consider the motion, ask questions, and approve or reject the motion. Approval in the PC is a simple majority of the PC members.

6.6 Subgroups of the TC Electronic Voting

The procedures for holding electronic votes (e-votes) presented in this section apply to any subgroup of the TC that:

• Has an email reflector on the OGC portal on which all voting members are subscribed; and
• Has a quorum rule on votes, or a rule that requires a notice to the TC at large of the type of vote being contemplated.

In the event that a motion is made either on the email reflector of a subgroup or in some other scheduled meeting of the subgroup (that lacks quorum and thus cannot act directly), then the chair (or presiding officer of the meeting if the elected chair is not present) may call for a portal vote as a “measures to obtain a quorum” (RONR, 11th Edition, §40, pages 347-348). The procedure will be as follows.

1. A motion is made and seconded on the subgroup’s email reflector or during a meeting (such as a teleconference) that may not have a quorum.^[11]
2. The chair (or the presiding person at the meeting where the motion was made in conjunction with one of the subgroup’s elected chairs) announces that a portal e-vote will be taken, and summarizes the procedure to be used. This summary includes an opening date (usually immediately or within one week after the motion is made) and a closing date at least one full week after the opening, making the vote last at least 8 calendar days (such as a Monday to Monday schedule).
3. All requirements for previous announcements as delineated in the TC policy and procedures must be met before the email or portal vote start date. These requirements may include posting of the associated supporting documents in advance of the vote and/or an official notice to the TC of a pending vote within the subgroup.
4. Votes must be cast before the end of the closing day at midnight in the time zone of the voter (as recorded by the email send protocol). This mail announcing the vote shall include a formal name for the vote in the subject field.
5. Any valid voting member of the subgroup  may visit the portal page for the e-vote and cast their vote. The member may change their vote at any time. The last vote cast by the member before the closing date and time is his official vote. Portal votes do not stop until their end date is reached or the vote organizer chooses to withdraw the vote.
6. Only one vote is allowed per OGC Member organization.
7. Protests on the procedures involving the vote will be addressed to the subgroup chair, with a final appeal to the TCC and the membership of the TC.
8. If at least a quorum of the subgroup votes (YES, NO or ABSTAIN) then the vote is valid. The original motion passes under the same rules as would have been required in an official meeting.

For most votes that require a simple majority at a quorum-valid meeting, the motion passes only if a quorum is obtained, and the number of YES votes is greater than the number of NO votes.

This procedure shall not be used to suspend the rules or to amend any motion made at a quorum-valid meeting of the subgroup.

6.7 TC or Subgroups of the TC Email Voting

The procedures for holding email votes presented in this section apply to any votes that the TC is eligible to hold in a Closing Plenary or any subgroup of the TC that meets the criteria for holding electronic votes as defined in Section 6.6. Note that use of the portal electronic voting function is preferred over the use of email voting procedures.

Email votes follow the same process as laid out for TC votes in the TC Meeting (see Section 6.4) or for subgroups of the TC electronic voting (see Section 6.6), with the following additional procedures.

1. The TCC or subgroup chair sends an email to the appropriate reflector notifying the group of the start of an email vote.  The message must specify the item(s) on which the group is voting, include relevant background information, provide the deadline for voting, and define the type of vote (“Hand” or “No Objection”).
2. “Hand” vote: voting members email the reflector (from the email address listed for the corresponding portal user) with the vote clearly mentioned in the first few lines of the mail, and optionally in the subject line. Allowed votes are YES, NO, or ABSTAIN. The subject line should include the formal name of the subject of the vote used by the chair in the announcement. A member may change their vote by emailing again at anytime before the close of the vote. The last vote cast by the member before the closing date and time is that member’s official vote.
3. “No Objection” vote: an email vote may consist of a request to the group members for any objection to unanimous consent.  Voters with no objection to the ballot do not need to email the chair or reply to the vote announcement. Should there be an objection, the vote will be paused and the objection discussed in the reflector or in a meeting.  If the objection is addressed to the satisfaction of the objecting party, the vote will continue for the number of days remaining in the vote from the date at which the vote was paused.  If the objection is not removed, then the vote will restart as either a “Hand” vote (see 2 above) or a portal e-vote.

7.0 Policies and Procedures for Subgroups of the TC

This section describes the Policies and Procedures for Sub-groups of the TC. This includes Domain Working Groups (DWGs) and Standards Working Groups (SWGs).

7.1 Membership in TC Subgroups

A subgroup is composed solely of representatives of current OGC members and (potentially) Invited Guests. Each type of group is chartered by simple majority vote of the TC in the course of normal business, and ratified by the PC.

The following rules apply to membership in subgroups of the TC.

• Any OGC member organization may send representatives to attend any meeting of the TC or any subgroup of the TC, even if voting in that group has been closed. The exception is for SWGs. In order to attend a meeting of a SWG, the representative must have opted into the SWG in order to participate (section 7.7.3).
• A Working Group may close their voting memberships for particular Items, but are not required to do so (except in the case of Standards Working Groups). The reasons for closing a WG include delineation of quorum and voters for voting reasons; avoidance of late vote-packing in the subgroup; and creation of a working core of people. In order to close WG voting membership, the WG must announce the deadline for membership requests a minimum of twelve weeks in advance, to the entire Technical Committee.
• Invited guests may actively participate at the sole discretion of the subgroup’s chair. That is, in the interests of ensuring the efficient operation of any meeting, the chair may limit or eliminate the opportunity of any invited guest to participate in discussion at any meeting. Invited guests cannot vote.

7.2 Role of Subgroup Chairs

The chair of a subgroup is responsible for organizing the activities of that subgroup, including:

• Arranging meetings at times and places convenient for the subgroup membership;
• Announcing meeting arrangements to the entire OGC membership, including a preliminary agenda for the meeting, at least 2 weeks in advance of the meeting;
• Encouraging broad participation of the OGC membership;
• Ensuring that minutes of meetings are taken, and made available electronically to the entire OGC membership within two weeks of the meeting. Minutes must include:
  1. A list of persons attending the meeting;
  2. A list of motions, seconds, and outcomes; and
  3. A section that details specific actions taken by members of the subgroup;
• Sending electronic reminders to action holder’s one week before the action is due for completion;
• Ensuring the smooth and orderly running of the meeting;
• Reporting on subgroup activities to the parent body, and PC if requested, including presenting subgroup recommendations (if any);
• Keeping the Chair of the parent body apprised of the progress of the subgroup; and
• Recommending schedule and work plan and managing subgroup resources to accomplish the mission of the subgroup.

7.3 Inactive Subgroups

The TCC will provide a list to the TC at least once a year of those subgroups that have not met in the previous 12 months. The TC will then vote to determine if these groups should be continued, disbanded or possibly combined with more active groups.^[12]

7.4 Subgroup Meetings

Subgroups except as noted above may set their own meeting schedules. In particular, they do not have to meet every time their parent body meets, nor are they prevented from organizing meetings not co-located with those of the parent body, provided that in every case the relevant meeting notice and reporting criteria are met (see section 5.1). However, there are some restrictions on the decisions that a Working Group may take at a meeting that is not co-located with that of its parent body.

7.5 Formation of a Sub-Group/Working Group

At any time, a group of Members may determine that a new area of technology or domain exploration is required. This interest may lead to the formation of a new OGC Working Group. The following are the usual steps related to the formation of a new WG. Typically, the first step is to call an ad-hoc meeting at a face-to-face TC meeting. An ad-hoc meeting is to 1.) judge interest in forming the new sub-group and 2.) define the scope of work for the proposed new sub-group.

7.5.1 Ad-hoc Meeting(s)

Any group of OGC members can schedule an ad-hoc meeting. The interested members develop a basic agenda and draft mission statement for the work of the group and call for an ad-hoc meeting at a scheduled TC event or by teleconference/webinar.  Like any sub-group, they shall schedule a meeting time and post the meeting time information on the OGC portal Calendar. Also, like any other sub-group meeting of the TC, they shall announce the meeting to the broader TC and communicate an agenda. At this Ad-hoc meeting, the participants continue to frame the mission and the scope for a proposed new WG or other OGC activity. They must also determine whether there is adequate Member interest to actually form a new WG.

7.5.2 Development of a proposed Sub-Group Charter

The primary function of the Ad-hoc meetings is to write a Charter for the new sub-group/Working Group. The Charter documents the mission, scope, roles, and responsibilities of the proposed WG. Drafts of the Charter can be shared with other members for review and comment. The templates for the Domain and Standards WG Charter documents can be found here:

• DWG Charter: https://portal.opengeospatial.org/files/?artifact_id=3247
• SWG Charter: https://portal.opengeospatial.org/files/?artifact_id=25120

7.5.3 Approval of a Sub-Group Charter

Once the Charter is completed and agreed to by the members of the Ad-hoc^[13], the following process if followed for approval of the Charter. NOTE: For a SWG Charter, please review section 7.7 of the PnP for specific requirements related to the formation of a Standards Working Group (SWG).

• The charter is reviewed by the Technical Committee Chair (TCC). The TCC shall provide edits and comments in a timely manner.
• The ad-hoc considers the TCC comments and edits the charter as necessary.
• The charter is assigned an OGC document number and posted to pending documents.
• The availability of the draft charter is announced to the TC and to the public and a three week public review period begins. There is a formal press release with a general call for comments.
• If possible, the draft charter is presented to the TC at a plenary. Otherwise, a PowerPoint or video presentation will be developed and posted to the portal. NOTE: For a SWG, this document or video should cover the key aspects of the charter, especially the scope of work, the timeline, and the technical discussion related how the standards work aligns with the current OGC standards baseline.
• Comments received during the comment period are considered by the ad-hoc members and any necessary changes to the draft charter are completed.
• The modified charter is posted to pending as an update with a new revision number. The TCC shall notify the membership that a revision of the charter has been posted.

7.5.3.1 Votes to approve the charter and formation of a sub-group

This section describes the voting associated with the approval of specific types of sub-groups: Committee, Domain Working Group, and Standards Working Group. In all cases, the TCC makes the motion to approve the charter for the new sub-group of the TC.

• Committees: Charters for and formation of subcommittees and committees may be approved by a simple majority vote of the membership. These votes happen at the Closing Plenary during a Face-to-Face TC meeting.
• DWG: The approval of a charter for a DWG is a simple majority vote of the membership. These votes happen at the Closing Plenary during a Face-to-Face TC meeting.
• SWG: This is a TC Voting Member vote. Approval of the charter is a simple majority. The TCC initiates a vote to approve the Charter and the formation of the SWG. This is an electronic vote under the e-vote rules as stated in section 6.5 (e-votes) above. The TCC shall also send an informational email to the full TC membership asking if there are any final comments or objections to the formation of the new SWG.

If the TC approves formation of the new group, then the TC makes a recommendation to the Planning Committee (PC) to approve formation of the new sub-group. These votes may happen at face-to-face meetings or by email votes or by a PC e-vote.

Upon approval of the TC and the PC, the new group will become an official subgroup of the TC.

7.6 Policies Specific to a Domain Working Group

This section describes the formation, role, and responsibilities of a Domain Working Group (DWG).

7.6.1 Voting in a DWG

Voting in DWGs is by simple majority of OGC Members present at the DWG meeting, not just Voting TC Members, with the caveat that no OGC Member organization may cast more than one vote in a WG vote.^[14]

7.6.2 Changes to a DWG Charter

The members of a WG may at anytime determine that a change to the WG charter is necessary. Such changes may be done at any time. The WG members need to approve the amended charter by a formally recorded vote. Once the WG members approve the amended charter, the Chair shall inform the TCC who shall then notify the full membership. The amended charter shall be posted to pending documents for a 3 week member review and comment period. The review period is followed by an approval vote by the TC. Please refer to 7.5.3 above.

7.7 Policies Specific to a Standards Working Group (SWG)

A SWG may be formed whenever:

• Three or more members provide an RFC submission for a candidate standard;
• One or more Change Request Proposals for a given adopted OGC standard have been submitted to the public Change Request repository on the OGC web site;
• Three or more members wish to define and document a new candidate OGC standard that will be submitted using the OGC RFC process; The new candidate standard could be an interface, encoding, profile, application schema, or extension package; and/or
• Three or more members wish to bring an external document into the OGC process and wish to collaborate to prepare this document for submission using the RFC process.

The formation and execution of the work of a SWG is closely tied to the OGC Intellectual Property Policies and Procedures. Members are strongly encouraged to read this Policy prior to forming or joining a SWG.

Whenever a SWG needs to be formed, the first order of business is to inform the TCC The TCC will discuss the process and next steps. The TCC shall announce to the full Membership via OGC communications that there is an intent to start a new SWG (standards) activity.

The submission team then writes a SWG Charter. Please review the OGC ad-hoc meeting and charter creation and approval process as outlined above in section7.5.3. The policies and procedures defined below are in addition to the requirements to form an OGC Domain WG.

7.7.1 The SWG Charter

The Charter documents the scope of work, references, business value, and projected timeline for the new SWG. There is a formal OGC template for a SWG charter. This template may be downloaded from:

 https://portal.opengeospatial.org/index.php?m=public&subtab=templates&tab=2

7.7.1.1 IPR rules for a new SWG

The charter of each SWG shall also specify whether the SWG to be formed is a RAND^[15]-Royalty Free SWG or a RAND- for Fee SWG. For a complete discussion of the OGC Intellectual Property Rights (IPR) policies, please refer to:

http://www.opengeospatial.org/about/ipr

The OGC IPR policy is similar to those of other voluntary standards organizations.

7.7.1.2 Persistent SWGs

Ordinarily, a SWG completes the work as defined in the Scope of Work and then disbands. However, there are cases in which a SWG needs to be “persistent”. These cases include the ability to work on multiple revisions of an existing OGC standard or to insure that long-term collaboration with other SWGs can be maintained. In this case, the Charter Members can request that the new SWG have a status “Persistent”. The Charter template has a section that specifies whether a SWG is persistent or not. By default, OGC SWGs are persistent until the SWG elects to become inactive or disband.

7.7.1.3 SWG Charter Approval and Formation

The TCC will work with either the candidate standard submission team or an interested group of members that wish to craft a new OGC standard to write the draft SWG Charter. Once a draft is completed, the charter review and approval process as defined in Section 7.5.3 shall be followed. For the purposes of charter development and approval, consider that the ad-hoc group and a submission team are equivalent in that a submission team is an ad-hoc group.

The SWG cannot begin business until the charter is approved.

Once the charter is approved by the TC and the PC, OGC staff will create a new portal project for the new SWG. Formation of the new SWG will be announced to the membership.

Finally, the TCC shall make a general call for participation in the new SWG. The call for participation will be made public.

7.7.2 “Charter” members of the SWG

The charter members for a SWG will be:

• Any members that are part of an RFC submission team;
• Any member who asks to join the SWG during the three week SWG Charter review period; and
• Any members who participate in the development of the Charter for a new SWG.

Charter members have agreed to the IPR terms of the SWG. Charter members are immediately vested in the work of the SWG and can vote on any items or issues during the first meeting of the SWG.

7.7.3 Participating in a SWG – Opting In

Any OGC member representative can join a SWG at any time and participate in the work of the SWG. If a Member wishes to participate, then the member representative(s) need(s) to “opt-in” to the new SWG in order to participate. Opting into a SWG is done via a registration page for that SWG. The registration page will be available on the OGC portal. The registration page will clearly state the IPR terms for the SWG as well as the Scope of Work.

If the member representative does elect to participate (opt-in), then there is a 30-day period during which the member representative can participate but cannot vote. During this 30-day period, the member representative can also elect to opt out of the SWG and not be required to declare any IPR or essential claims.

7.7.4 SWG voting members

All of the SWG charter members can vote at the first meeting of the new SWG and are therefore deemed “voting members” of the SWG.

After the 30-day waiting period, any member representative who is not a charter member may request that the SWG chair change their status to a voting member of the SWG. Once the Chair approves the request, the member can then vote on any item or issue brought before the SWG. Any member who has been participating in a SWG for 30 days but does not wish to be a voting member can remain of group member and participate.

7.7.5 “Opting in” to participate in a SWG

Any member representative opting into a SWG and making a Contribution to any SWG (regardless of its licensing designation) must commit at the time of making such Contribution that if the Proposed standard in connection with which the Contribution is made is finally approved by OGC, the Contributor will provide a License to all patent claim(s) Owned by it that become Necessary Claim(s) by reason of its making a Contribution, without compensation and otherwise on a RAND basis, to all Implementers.  Such commitment shall be made be made pursuant to a written declaration in the form of Appendix A to this IPR Policy.

7.7.6 Opting Out of a SWG

If during the 30-day waiting period, any member representative may elect to opt-out of a SWG without having the Member having to declare any Necessary Claims. A member representative can opt-out by notifying the TCC and/or designee representative.

7.7.7 Election of SWG Chair and Co-Chair

The first order of business of a new SWG is to elect a Chair and Co-chair. The Chair and Co-chair must be from different Member organizations. When there are adequate nominations or volunteers for the Chair/Co-chair, the SWG Convener will call for a vote of members who have opted in to participate in the SWG. In the case where there is only one nomination for Chair and one for co-chair, the SWG Convener will ask the SWG members whether there is any objection to unanimous consent. The election of a Chair or Co-Chair can happen at either a TC Meeting or via email. The election of the Chair and Co-Chair does not require TC or PC approval. Once the election is complete, the new Chair shall notify the TCC of the results of the Chair and Co-chair election.

7.7.8 Cross SWG Communication

Many technical issues discussed in a SWG will require collaboration and communication with other SWGs. As long as the voting members agree to such cross SWG communication, then an open dialogue between two or more SWGs can occur on any specific technical issue.

7.7.9 Responsibilities of the SWG Chair and Co-Chair

In addition to the sub-group Chair and Co-chair responsibilities as outlined in Section 7.2, the SWG Chair is responsible for organizing the activities of the SWG, including the following.

• Ensuring that minutes of meetings are taken, and once approved by the SWG voting members and made available electronically to the SWG membership within two weeks of the meeting. Minutes must include:
  • A list of persons attending the meeting and determining if there is quorum;
  • A list of motions, seconds, and outcomes; and
  • A section that details specific actions taken by members of the subgroup.
• Reporting on subgroup activities to the TC and if the SWG meetings during a TC meeting, presenting at the closing TC Plenary, including presenting subgroup recommendations (if any). Any reports to the TC SHALL be approved for release by the SWG voting members.
• Maintaining SWG member status on the portal (voting, observer, etc).
• Ensuring that issues are logged into the portal and these issues are prioritized and put into a roadmap for completion of a revision (or a future revision). Further, that the Chair ensures that the pertinent standard roadmap is updated, agreed by consensus of the SWG members, and posted at least for each regularly scheduled TC meeting time.
• Ensuring that issues worked result in official change proposals and that only these official change proposals shall be considered by the SWG.

In the event that the Chair is not able to fulfill these duties, the Co-chair will step in and assume the leadership role until such time as the Chair is able to resume their duties. Failure of the Chair and/or Co-chair to provide these capabilities will result in the removal of the Chair and the election of a new Chair. If no suitable Chair can be located, then the work of the SWG will be considered to be non-critical and the SWG will be dissolved.

7.7.10 SWG Voting

SWGs operate under the same general voting rules as other sub-groups of the TC, namely Votes in an SWG follow the same guidelines as for the Technical Committee except for how a quorum is computed. See the section above for the procedure for email votes for sub-groups of the TC. The one notable exception related to SWG votes is that only member representatives who have opted into the SWG may vote.

7.7.11 Caveat on Voting Rights – If you do not participate on a regular basis

If you join a SWG and have voting privileges, you have a responsibility to participate in the teleconference and email dialogues. If you do not participate in the teleconferences and email discussions and vote on items and issues, you will lose your voting privileges and have your SWG member status changed from “Voting” to “Group Member”. The SWG Chair has the authority and the ability to make these changes based on the following policy:

Quorum for votes on any items or issues brought before a SWG is based on the number of voting members for that SWG. Insuring quorum at SWG meetings is a vital aspect of the SWG being able to complete its work in a timely manner. Therefore, any SWG voting member who misses two consecutive SWG meetings (teleconference, face to face, or webinar) in which votes occur or misses two consecutive email votes shall be deemed as inactive and will not count toward quorum after the second missed vote. The SWG Chair shall take roll call at the beginning of each meeting and determine quorum based on active voting members only. An inactive SWG voting member can become active again simply by attending the SWG meetings and participating. If regular attendance by a given voting member is an issue, that voting member may assign a temporary or permanent proxy to another SWG voting member or to the SWG Chair. The voting member may rescind that proxy at any time. If the voting member wishes not to assign their proxy, they can ask to change their status to “Observer” and still actively participate in the SWG.

7.7.12 Public Release of SWG Documents

At any time, the SWG voting members may agree to release any SWG in-progress technical document into a public forum, such as OGCNetwork, to another standards organization, or to the public for comment. Such an action requires a formal SWG motion and SWG e-vote as per 7.7.10.

7.7.12.1 Release of document(s) for public comment

At any time, the SWG can vote to release an in-progress candidate standard for public comment. Please remember that there is the official formal 30 day public comment period. However, a SWG is encouraged to release an in-progress document early in the process in order to solicit input from the community. If a SWG votes to release a document for early public comment, it must coordinate with OGC Communications to generate a press release and properly create the Call for Comments (RFC) on the OGC website.

7.7.13 Umbrella SWGs

From time to time, two or more existing SWGs need to collaborate and coordinate on a regular basis. In such cases, the SWGs may propose to create an umbrella SWG. To create an umbrella SWG:

• All affected SWGs shall vote to agree to participate in the umbrella SWG;
• All affected SWGs shall have the same IPR policy; and
• The existing charters for the affected SWGs shall be updated to state that the SWG is part of an umbrella SWG.

Once approved, the existing operational SWGs will be dissolved and reformed under the new IPR umbrella. All existing voting members would remain voting members in their respective SWGS. However, opting to participate in one SWG shall mean that the member is opting as an observer to all SWGs that are part of the umbrella SWG.

8.0 Document Types and Document Processes of the TC

This section describes the various OGC documents and document handling processes that are the responsibility of the TC.

8.1 An OGC Policy Document

A policy is a principle, rule or process that guide decisions to achieve rational outcome(s). The work of the OGC is guided by a number of Member approved policies and processes. These policies and processes are documented in various OGC Policies and Procedures documents. These shall be known as “Policy” documents. This TC P&P is a policy document. Policy documents are either maintained by the Members or by OGC staff. In all cases, new policy documents or revisions to existing policy documents shall be reviewed and approved by both the Technical and Planning Committees. Approval of a policy document shall follow the e-voting rules as defined in section 5.5 above. If the TC approves the Policy document, then a simple majority of the PC Voting Members must approve the TC recommendation.

Policy documents have version numbers that shall start at 1.0

8.2 The Standards Document

An OGC standards document is the principal document type that captures the work and the consensus of the OGC membership. Standards documents must use the OGC standards document template (with the exception of Community standards^[16]) that can be downloaded from: http://portal.opengeospatial.org/index.php?m=public&subtab=templates&tab=2 .

OGC uses a  multi-track standards policy with three possible states: OGC Community standard, OGC standard, and OGC standard with Compliance Suite. These are described in Section 9.3.

Approval of an OGC standard is described in section 9.0 of this document.

Each standard distributed by the OGC shall include a cover page with the statement as specified in section 4 of the Policy Directives for Writing and Publishing OGC Standards: TC Decisions.

Standards documents have version numbers that shall start at 1.0

8.3 The OGC Reference Model

The TC will periodically be asked to review and vote on the OGC Reference Model (ORM) Document. The ORM describes a framework for the ongoing work of the OGC and our standards and implementing interoperable solutions and applications for geospatial services, data, and applications. The ORM can be found at:

http://www.opengeospatial.org/standards/orm

Any version of the ORM, once approved by the TC and the PC, is released as a public document.

8.4 Discussion Papers

DWGs shall often be used to hear presentations in their interest area. Further, a DWG can generate Discussion Papers for the industry covering a specific technology area germane to the DWGs’ interest area. In either case, the DWG makes a recommendation to the TC for release of the document as a Discussion Paper.

Motions to approve release of a document as a Discussion Paper may originate from a DWG with TC approval, from a motion at a TC Plenary, or from a motion by the TCC.

While these Discussion Papers shall be distributed by the OGC, and might in fact lead to adopted standards later, they do not represent an official position of the OGC TC or the OGC itself. Each Discussion Paper distributed by the OGC shall include a cover page with the statement as specified in section 4 of the Policy Directives for Writing and Publishing OGC Standards: TC Decisions.

Discussion Papers do not have a version number.

8.5 Public Engineering Reports

Any OGC Interoperability Initiative, such as a Test Bed or Interoperability Experiment, will have Engineering Reports (ER) as a deliverable. These ERs are typically posted to pending documents and presented and discussed in a DWG at an OGC TC face-to-face meeting. The DWG may recommend to the TC that the ER be publicly released. If approved by the TC, these documents shall be released as “Public Engineering Reports”.

While these ERs shall be distributed by the OGC, and might in fact lead to adopted standards later, they do not represent the official position of the OGC TC or the OGC.

Motions to approve release of a document as an Engineering Report may originate from a DWG with TC approval, from a motion at a TC Plenary, or from a motion by the TCC.

Each Public Engineering Report distributed by the OGC shall include a cover page with the statement as specified in section 4 of the Policy Directives for Writing and Publishing OGC Standards: TC Decisions.

Engineering Reports do not have a version number.

8.6 Best Practices Documents

OGC Members, TC subgroups, or Interoperability Initiatives may generate Best Practices (BP) Documents for the industry covering best practices related to the use of an OGC standard or other technology relevant to one or more OGC standards. A best practice is a technique or methodology that, through experience, implementation and research, has proven to reliably lead to a desired result.

BP documents have version numbers that shall start at 1.0.

8.6.1 Submission of documents to be considered as an OGC Best Practice

In order to be considered for approval as an OGC BP, the document submitters shall provide the following.

• Evidence of implementation. Evidence of implementation shall include but not be limited to: Implementation in commercial product, implementation in open source applications or software, and/or implementation in deployed applications. A single research related implementation is not proper evidence of implementation.
• A short (one page or less) written justification explaining why a submitted document should be considered for approval.
• Presentation of the contents of the proposed BP at an OGC face-to-face meeting. The presentation may be done remotely using OGC communication tools, such as GoToMeeting.
• Post the document to OGC Pending Documents on the OGC Members portal for at least three weeks prior to the face-to-face presentation.

8.6.2 Approval of OGC Best Practice Documents

A BP is an official OGC position statement. Therefore, BP Documents shall be approved by formal electronic vote. Motions to initiate a BP e-vote may originate from a DWG with TC approval, from a motion at a TC Plenary, or from a motion by the TCC.

A BP vote has the same rules as a standards adoption vote (Section 6.5).

The BP document authors shall respond in writing (email is acceptable) to any comments received during the voting period. If necessary, the document authors shall edit the document. If the TCC deems that the edits to the document are more than editorial, then the document shall be posted to pending and a new BP approval e-vote shall be initiated.

Each Best Practice Paper distributed by the OGC shall include a cover page with the statement as specified in section 4 of the Policy Directives for Writing and Publishing OGC Standards: TC Decisions.

8.7 Documents and Distribution

The numbered document (see 8.7.1) as distributed to members is to be considered the official document of the TC. Electronic mail shall be used for day-to-day discussion of OGC documents. The preferred mechanism for document sharing is the OGC Members only portal. OGC Communication shall be used for announcing the availability of new official documents. The actual documents will not be distributed by email unless a member requests receiving a document by email. All official documents will be posted to the Portal. Other electronic forms of documents can be made available at the written request of members.

The Members section of the OGC portal (http://portal.opengeospatial.org shall provide the default method of disseminating documents in electronic form. The TCC or his designee shall determine the electronic distribution format^[17] of these documents. RFC proposals, Discussion Papers, Best Practices Documents, and Engineering Reports must be provided in one of the formats defined in Section 8.7.4. However, the preferred document format is the Word .doc format. The format for dissemination may change as distribution technology changes. Up until mid 2014, all approved Abstract Specification and standards were only available in PDF format. Please note that the OGC has moved to publication of OGC standards documents in HTML^[18].

8.7.1 Document Numbers

All member submitted documents shall be assigned a document number. Members can obtain pending document numbers using the members only portal, OGC Pending Documents page located at http://portal.opengeospatial.org/index.php?m=public&orderby=Manage&tab=2.

Instructions for obtaining a Pending Document number and posting the document can be found at: http://portal.opengeospatial.org/index.php?m=public&subtab=instructions&tab=2.

8.7.2 Document version numbers

The guidelines for version/revision numbers for documents are as follows.

• All non-specification/standards documents do not have version numbers at publication.
• Only approved OGC standards have document numbers 1.0.0 or greater. The first approved version of an OGC standard shall be version 1.0.0.
• Corrigendum releases shall NOT result in any change to the major/minor number. If the standard being revised has schema, then the schema shall use the version attribute to document the revision number at the third level.
• Revisions to an adopted standard typically result in a change to the minor number. For example, the first revision to an adopted 1.0 standard would be 1.1.0. Minor revision releases should be 100% backwards compatible with the previous version.
• Changes to the major version number are reserved for when there are significant changes to the adopted standard or when backwards compatibility cannot be maintained with the previous version.

8.7.3 Change Proposal Format

Change Proposals for any OGC document shall use the procedures and format as documented in section 9.10.

8.7.4 Other Document Concerns

All documents with official OGC Document Numbers that are to be considered and discussed at a TC face to face meeting shall be made available electronically to all members at least three (3) weeks before the next Technical Committee meeting. However, this clause does not apply to informational documents for which there will not be any motions or actions. Numbered documents shall be posted to Pending Documents.

The TC will enforce this policy under the conditions described in paragraph 6.3.

All documents shall be made available in one or more of the following formats:

• Word for Windows including .docx^[19] format (preferred for proposals and other textual documents),
• Rich Text Format (RTF),
• Portable Document Format (PDF),
• Hypertext Markup Language (HTML),
• PowerPoint (preferred for presentations), or
• ASCII Text.

8.7.5 Policy for the Retirement of OGC Documents

This section provides the policy and procedure for retiring OGC documents. “Retirement” criteria can be based on one or more of the following:

• A document is no longer technically up to date;
• A document is not actively downloaded from the OGC website;
• A document is no longer considered to be of interest by the Membership;
• The document is no longer valid due to new OGC documents being published; or
• For a standard, no one is implementing the standard.

At the one-year anniversary for a Discussion Paper, the two-year anniversary of a Public Engineering Report and at the three-year anniversary of any standards document^[20], the OGC shall determine whether the document should be retired or remain an active Member document. The TCC shall compile a list of such documents prior to any OGC Face-to-Face meeting. The OGC Staff shall also compile download statistics. This information shall be compiled into a single document, posted to pending documents, and an announcement of availability broadcast to the Membership.

For discussion papers, public engineering reports, and best practices, the TCC shall create a set of motions related to documents for consideration for retirement by the TC Membership. The form of the motion shall be:

 “The TCC recommends that OGC document <xyz> remain an active OGC document”.

A positive vote indicates that the document shall not be retired. These motions shall be presented at the closing plenary at a TC meeting. Based on the results of the vote, the target documents shall either be retired or remain active.

In the case of a OGC standard, a formal electronic vote by the TC Voting Members is required to approve retirement. A retirement vote for a standard shall be 30 days duration. A simple majority of the active Voting Members is required to retire an OGC standard.

Retired documents are not removed from the OGC public website. Instead, they are moved from the current document archive to the “Retired” archive. Further, any retired document shall have “Retired” watermarked on the cover page. If there are schemas associated with a retired OGC standard, the schemas remain in the OGC schema repository. If there are compliance tests for the retired standard, the compliance tests are automatically retired but also remain available on the OGC web site.

9.0 Policies and Procedures for Adoption and/or Revisions of Standards

This section covers procedures for adoption, revision, and maintenance of OGC standards. For the purposed of clarity, the term “standards” covers both the candidate abstract and implementation cases.

9.1 General Subgroup and Technical Committee Recommendation Process

In general, all subgroup recommendations and voting procedures follow the process described in this section. The subgroup will reach the point of making a decision on recommendation of some action. The subgroup will vote to recommend that the TC take the action. If the vote is affirmative, then the TC will vote on the action. If the TC concurs with the subgroup recommendation, then the action is approved and further processes can carry the action forward, such as PC approval. If either the subgroup or the TC votes down the recommendation, then a determination of further action must be made. Exactly what happens depends on the nature of the action. For example, documents may return to submitters for further work, be forwarded to subgroups for more deliberation, and so forth. If no further action is required then the action is halted. If further action is required, then the subgroup or TC must define what the further action is and who is responsible.

9.2 Standards Proposed for Adoption – Caveats

Only Voting TC Members of the OGC may propose candidate standards for adoption by OGC.

All OGC standards adoption votes will be electronic. Only Voting TC Members may vote on an adoption vote. However, any OGC member regardless of membership level can 1.) be part of a team submitting a candidate document and 2.) join a SWG and work on a candidate standard.

The TC e-vote is to recommend to the Planning Committee (PC) approval of the results of an adoption vote. This will ensure that all TC voting members have the opportunity to vote on the most important work done by the Consortium. Lack of a vote does not count as a vote of Abstain; only an actual vote of Abstain counts as such a vote.^[21]

The policy of the OGC is that proposed standards resulting from an RFC evaluation may be recommended to the PC for acceptance conditional on certain changes to the standard, which the TC deems necessary, within a specified time frame.

Acceptance of the TC recommendation for adoption is always with the caveat that the PC may verify that the standard’s sponsor organization(s) is/are in a position to develop (or have developed for the sponsor organization) or commercialize an implementation of the standard. Further, for candidate standards developed external to the OGC and submitted into the OGC process, the PC may verify that the submitting organization has provided a duly executed submission of technology form. In addition, the TC recommends acceptance contingent on the PC’s finding that the sponsoring organization(s) makes the technology available as per the OGC Intellectual Property Policies and Procedures.^[22]

9.3 The Two Track Standards Process: Characteristics

There are two possible tracks for proposing and approving candidate standards or proposing and approving revisions to an existing adopted standard: The OGC Community standard and the OGC Full Standards track. These two tracks are described below. Regardless of the submission track, the OGC Request For Comment (RFC) Process shall be used. There are key differences in the RFC process depending on whether the Community or the Full Standard track is being used. The following table summarizes the key aspects and steps in the RFC process for the two tracks.

Community standard: This is a document, developed by communities external to the OGC, such as GeoTiff, that OGC members wish to bring into the OGC process. The key consideration for a Community standard submission is that there is very strong evidence of implementation. At the same time, the community owning the standard may not want to allow normative changes (except for errors) to the document, may not wish to follow the OGC Modular Specification Policy, nor do they wish to develop CITE tests. Please visit Section 9.5 and Annex C to read more about the requirements for submitting a Community standard as well as a checklist of steps in the Community standard submission, review, and approval process.

Full OGC standards track, which consists of two possible target levels of standard.

Standard: This is a document developed by the OGC membership, such as in a Testbed or in a SWG, for which there is no evidence of implementation or CITE tests. However, the members wish to approve the document as an official OGC document in order to have developers and organizations implement the standard and provide feedback. A standard may at some time be moved forward for approval as a standard with Compliance Suite or it may remain as a standard.

Standard with Compliance Suite: This is a mature OGC standard for which there is evidence of implementation and for which Compliance tests exist. A standard with Compliance Suite may start as a Community standard or as a standard.

9.3.1 Two Track Standards Process Criteria

Evidence of implementation: The TC will judge whether the evidence of implementation for a particular Community standard or standard with Compliance Suite is sufficient to warrant approval of that standard. Strong evidence of implementation as required for the Community standard is generally defined to be implementation in multiple products or environments OR widespread use of the standard in a community, even if in only one or a limited number of products or environments. Evidence of implementation for a standard with Compliance Suite is defined as three or more documented implementations that collectively implement all mandatory requirements of the standard. The TC may choose to override the minimum number of reference implementations for a specific candidate standard by specifying a lesser number in the electronic adoption vote.

Modular Specification: compliance with the Modular Specification is evidenced by inclusion of clearly defined Requirements and an Abstract Test Suite in the standard document. The OAB will evaluate a standard against this criterion.

Compliance Test: a compliance test for an Implementation standard is defined to be an OGC CITE test suite complete for all mandatory requirements in the standard. A compliance test for a Conceptual Model is defined as an approved OGC standard that encodes against the Conceptual Model and which itself has CITE tests.

IPR: Community standard may contain IPR that is jointly held by the OGC and the submitting organization. The Full Standards track requires that OGC hold the IPR.

9.3.2 Status of Standards Approved Before the Two Track Standards Process

OGC standards approved prior to the effective data of Revision 24 of these Policies and Procedures (05-020r24) will automatically be classified as “standards” under the Full Standard track. These standards can be advanced to a standard with Compliance Suite per the process defined in Section 9.5.7.

9.4 Adoption and/or Revision to a Standard - General

The Request for Comment (RFC) Process (Section 9.5) is the only way for a candidate standard to move through the review and approval process. This is the approach for proposing a new candidate standard, submitting an externally developed community specification into the OGC process, extensions to an existing standard, profiles of an existing standard, or an application schema for consideration by the membership. For the Full Standards track, a SWG manages the RFC process.

Please note: A new standards activity can also be initiated when there are outstanding change request proposals. Change Request Proposals (CRPs) (Section 9.11) provide details for revisions to existing Abstract Specifications or standards. A CRP describes proposed changes or enhancements to an existing standard. A CRP may be submitted by one or more OGC member organizations. One or more CRs against an existing OGC standard is evidence that a revision process for that standard should be initiated. In this case, the TCC may request members consider a standards activity using the RFC process.

The following section provides details on the OGC standard development processes.

9.5 Policies for the Request for Comment (RFC) Process

The following sections details the requirements, policies, and procedures for adoption of a candidate standard using the OGC RFC process. Each section specifies whether that step or requirement in the process is for All submissions, Community standard only, or Full Standard track only. Please also refer to Annex B of this document for a synopsis of the steps in the RFC process for the Full Standard track.

9.5.1 Conditions for Submission of an RFC

Any OGC Technical Committee Voting Member may make an unsolicited submission of a candidate standard or a proposal for the development of a new candidate standard using the RFC process given that for the submission, the following conditions are met.

• Three different Member organizations endorse the submission.
• A Voting Member is the lead for the submission team.
• For a candidate Community standard or a candidate standard with Compliance Suite there is evidence of implementation and evidence of a continued commitment to commercialize and/or support the implementation.
• For a Community standard, the submission team completes a written justification as to why the Community standard track is being requested.  This step is described in more detail below.
• All required documents (see below) must be ready for submission to the OGC for consideration through a Request for Comment (RFC) process.

9.5.2 Intent to Submit an RFC (All)

Any organization that intends to submit a candidate standard via the RFC submission process must inform the TCC via email or written correspondence that a new candidate standard is being submitted. At least three different OGC Member organizations must commit to being part of the submission team. The primary submitter must be a TC Voting Member. The TCC will announce via OGC Communications that there is intent to submit a candidate standard.

9.5.3 Terms and Conditions for RFC submissions (All)

In the RFC process, the submitters agree to the following set of terms and conditions.

• For a Community standard, work with OGC Staff to develop and submit a justification for submitting a candidate community standard
• For a Full Standard track submission, work with OGC staff to develop a new SWG Charter or to revise the Charter of an existing SWG.
• All RFC submissions originating from work done external to the OGC consensus process and then submitted into the OGC for consideration as an OGC standard may require a signed original of the OGC Submission of Technology Form^[23]. Work with OGC staff to determine if a SoT form is required. This form shall be provided to the OGC prior to the adoption vote.
• The Submission team has reviewed the current Policy Regarding Intellectual Property Rights of OGC and agrees that its submission is being made in full compliance with those Policies.
• Proprietary and confidential material may not be included in any submission to the OGC.
• RFC submitters must provide an agreement to grant OGC a non-exclusive, royalty-free, paid-up, worldwide license to copy and distribute their submission to the OGC membership, and, if adopted by OGC, the right to modify, enhance, and make derivative works from the standard and to copy and distribute the standard, modifications, enhancements, and derivative works both inside and outside of the OGC membership.
• The Submitters agree that the OGC may copy, distribute and otherwise make available this submission for the purpose of evaluation, and that in the event that the submission is accepted, that OGC will own the copyright in the resulting standard or amendment and all rights therein, including the rights of distribution.  This agreement shall not in any way deprive the Submitter of any patent or other IPR relating to the technology to which its submission relates.
• OGC standards may reference other OGC standards or standards from other standards organizations. Incorporating standards by reference requires that the standard clearly designate what portions of the other standard are referenced, the version of the other standard, a complete reference to the other standard, and complete information on how to obtain the other standard. Whenever possible, submitting organizations are asked to make available to OGC the referenced standard in soft or hard copy form.

9.5.4 Specific process requirements for the submission of a Community standard (CS)

9.5.4.1 Notify TC Chair

The submission team shall notify the Technical Committee Chair of the intent to submit a Community standard. This notification may be done using email. The notification shall include the organization names of the submission team. The notification shall also include agreement to the following statement:

The companies <list of companies/organizations> have granted the Open Geospatial Consortium (OGC) a nonexclusive, royalty free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version.

9.5.4.2 Submission justification document process

The submission team shall provide a written justification as to why the Community standard process can be used. This justification shall also include the reasons why the candidate standard may not need to be aligned with the OGC Abstract Specification and Standards Baseline. There is a template for this justification (OGC 16-113, Community Standard Justification Template). Please use the template!

Once the submission team completes a draft of the justification document, they shall provide the TCC the draft. The TCC shall review the draft and provide comments and guidance back to the submission team. The Submission Team reviews the TCC comments and modifies the justification as required. When the Submission Team agrees that the justification document is complete, the convener shall post the justification document to pending documents. The document shall be posted as a Public document!

9.5.4.3 Submission justification document: Member review process

Once the justification document is posted to pending, the TCC shall:

• Announce a three week OGC Member review period. Comments may be provided.
• Coordinate a broad community announcement that the OGC is considering accepting a Community standard into the OGC standards process;
• Ask the full TC if there are any objections to accepting the proposed candidate Community standard as an official OGC work item. If there are objections, comments shall be provided.

Please note that there is also an official TC Voting Member vote to approve the use of the Community standard process.

9.5.4.4 Approval of the proposed Community standard as an OGC work item

Concurrent with the Member review and comment process, the TCC shall initiate an

official e-vote to approve (or not) the proposed work item for processing a Community

standard. This vote shall follow the e-vote process and policies as defined in section 6.5 of the

OGC Technical Committee Policies and procedures. If the approval motion fails, the submission shall be withdrawn and the submission team may resubmit the candidate community standard after addressing Member concerns.

9.5.4.5 Processing Comments received during the Community standard work item approval vote

If comments are received as part of the approval vote for using the Community standard process, the submission team shall follow the process as defined in 9.5.6.7.

9.5.5 Required components of the RFC Submission Package

In addition to the candidate standard document, all RFC submissions must include a signed Cover Letter and if required a signed OGC Technology Submission form for each submission.

9.5.5.1 Submission Cover Letter (All)

The lead organization on each RFC submission shall provide a Cover Letter stating the intent of the organization to support the SWG and related RFC process. The cover letter may be in the form of an email correspondence.

If the organization submitting the Cover Letter is committing to commercialize the standard, then the letter must contain a commitment to make the implementation available on commercially reasonable terms, applied in a non-discriminatory fashion within twelve months of adoption by the OGC Planning Committee. The suggested words for the cover letter can be obtained from the OGC.

9.5.5.2 OGC Technology Submission Form (Externally developed submissions only)

The following clause applies to candidate standards developed external to the OGC and then submitted by the Members for consideration as an OGC standard.

Assurances are required at the time of submission that the Intellectual Property Rights inherent in the submissions will, if the submission is approved as an OGC standard, be made available under license to all implementers, members and non-members alike. 

In order to assure this result, any organization submitting a RFC Proposal Package where the candidate standard was developed outside the OGC SWG or DWG process may be required to complete, sign and deliver a Submission of Technology Form. Please contact OGC staff to discuss whether a SoT is required. If required, the signed SoT shall be provided prior to the adoption vote.

9.5.5.3 Additional Member endorsements (All)

Any submission requires that three or more distinct Member organizations support the submission. In addition to the submission team lead, each other organization supporting the submission share provide the TCC with an email stating their organization’s support of the submission.

9.5.6 Main Steps in the RFC Process

The steps in the OGC RFC Process are as follows.

9.5.6.1 Submission of the RFC package to the OGC (All)

The RFC Submission team shall provide the submission package to the OGC TCC. The TCC shall review the proposal in terms of required documents.

For a Community standard, the submission package shall include:

• Cover letter,
• Endorsements,
• Justification document (see above 9.5.4.2),
• Agreement in writing that the OGC has rights to use, modify, copy, and distribute the candidate standard (See above 9.5.4.1), and
• Candidate standard document.

For a Full Standard, the submission package shall include:

• Cover letter,
• Endorsements,
• SWG Charter (See below), and
• Candidate standard document if one exists. For proposed new standard, providing a document is not required.

Documents being submitted as Full Standards shall use the document formatting and content, in common use by the OGC at the time of submission, of standards submitted under the RFC process. There is a detailed guidance document for using the template.

Documents being submitted as Community standards do not need to follow the OGC document template for an OGC standard. However, the submission team for a Community standard is strongly encouraged to provide the candidate standard to the OGC using the document template.

Proposals that require changes to the Abstract Specification must include acceptable documentation (at the discretion of the OGC TC) of these changes.

9.5.6.2 Formation of a new SWG to work on the RFC submission (Full Standard)

See section 7.7 on the Policies specific to the formation of a new SWG and SWG processes.

9.5.6.3 Release of candidate standard for Public Comment (All)

Community standard: When the submission team agrees that the candidate standard is ready, they can request an official 30 day public comment period. The request requires a formal OAB review as specified in 9.5.6.4.

Full Standard: At any time in the RFC process the SWG may vote to release a candidate standard for public comment. These interim public comment periods do not require OAB review or OGC Naming Authority review. However, there shall be at a minimum one official 30 day public comment period. Once the SWG determines that the candidate standard is ready for OAB review and public comment, the SWG shall have a vote to release the document for public review. Upon a simple majority vote by the voting members of the SWG, the candidate standard will be released for a 30-day public comment period. The OAB shall review a candidate standard prior to the actual release for public comment.

9.5.6.4 Review by the OGC Architecture Board (All)

Once the SWG or Community standard Submission team approves the candidate standard for public comment, the candidate standard is reviewed by the OAB. The OAB has the responsibility to insure that the RFC submission is relevant in terms of the rationale for how the candidate standard fits into the current adoption plans of the OGC (and/or the current Abstract Specification), for Full Standards compliance with the Modular Specification Policy^[24], and how the proposal is consistent^[25] with the current OGC standards baseline.

9.5.6.5 Review of OGC Identifiers (http uri’s, etc) by the OGC Naming Authority (All)

Concurrent with the OAB review of the candidate standard, the SWG shall provide a list of all new OGC identifiers specified in the candidate standard to be issued for persistent public OGC resources. This list shall be submitted to the OGC Naming Authority for review. This submission may be done by email. The specific policy is specified in “Policy Directives for Writing and Publishing OGC Standards: TC Decisions”.^[26]

In order to facilitate the review and to be in compliance with the OGC http uri policy [OGC 06-135 – Directive 21], the editor shall submit the candidate standard’s list of doc^[27], spec and XML Namespace URIs for OGC-NA review formatted into an Excel spreadsheet or as a Persistent Uniform Resource Locators (PURL)^[28] configuration document, which is valid according to the batchPurls.rng schema.

9.5.6.6 Release for Public Comment Period (All)

The candidate standard is released for a 30-day public comment period^[29]. During the RFC comment period, any party (including all classes of OGC members, as well as any non-member of OGC) may send comments on the proposal to OGC Headquarters or to the address announced with the RFC issuance.  OGC staff will manage collection of the comments. OGC Communications will insure that the SWG or Community standard submission team membership is informed regarding submitted comments. It is important to note that anyone may make a comment on an outstanding RFC.  RFC’s are available to the public, not just members and are publicized.

9.5.6.7 Review of the Received Comments (All)

Once the RFC comment period closes, the RFC submission team “collects” the comments and integrates them into a single RFC comment document. The team reviews the comments and determines how each comment will be responded to. The team may decide to:

• Accepts the comment as is and edits the candidate standard accordingly;
• Accepts the comment with modification and edits the candidate standard accordingly;
• Accepts the comment as a future work item; or
• Rejects the comment with an associated reason.

In all cases, the team shall document their decision in the RFC comment document. Further, the team shall notify each individual who submitted a comment as to the disposition of the comment. This could be done by pointing the individual to the public comment response document.

The comment response document shall be a public document. The comment response document can be a Word document or a Wiki (preferred).

Finally, the team may need to make a decision as to the fate of the RFC. If the team decides that comments received are sufficient to halt the RFC, then the RFC “fails” and adoption of the proposal halts.  The submitter(s) may then make changes and resubmit the RFC proposal. 

If, however, the comments received do not cause the team to halt the RFC, then the team edits the document based on the comments received during the comment period (See above).

9.5.6.8 Member briefing for Candidate standard (All)

Once the final document has been posted to pending, the submission team shall brief the TC Membership on the contents of candidate standard. This briefing shall occur prior to a final adoption vote. This briefing may be at a face-to-face meeting or via an official OGC GoToMeeting session (webinar). The briefing shall be announced via formal OGC communications at a minimum of three weeks prior to the briefing. Further, if the briefing is via a webinar, the submission team shall identify two separate dates and times for the briefing. This is to accommodate OGC members in all time zones. Alternatively, the submission team may create a video of a briefing and make this video available to the OGC membership.

9.5.6.9 Vote to Approve Candidate standard (All)

After the candidate standard has been briefed to the TC, the TCC will request that the TC approve the start of an electronic vote to recommend approval of the candidate standard by the PC.  This vote can occur in a Plenary (see Section 6.4.2) or via email (see Section 6.7).

Upon approval of the TC to start an electronic vote, the TCC will initiate a 45 day electronic vote to recommend approval of the candidate standard by the PC.  This vote will follow the rules specified in Section 6.5.

A YES vote by the TC to recommend approval by the PC will initiate a PC vote, further described in the PC Polices and Procedures.

9.5.7 Specific policies regarding approval of a standard with Compliance Suite

A standard proposed to be approved as a standard with Compliance Suite must be submitted by the SWG to the TCC with written documentation that the standard meets the criteria for Reference Implementations and presence of a Compliance Test per Section 9.3.1. The candidate standard with Compliance Suite must then proceed with the OAB Review through Voting steps highlighted in Sections 9.5.6.4, 9.5.6.5, 9.5.6.6, 9.5.6.7, 9.5.6.8, and 9.5.6.9.

9.6 Specific Policies Regarding Abstract Specifications

The OGC Abstract Specification Development, Revision, and Approval process is the same as for any OGC standard except for documents that originated in ISO or are joint OGC-ISO standards activities. Section 9.6.2 provides details on the approval of such documents as OGC Abstract specifications.:

9.6.1 Scope and Content

The scope of the Abstract Specification (AS) will include any items that the OGC Technical Committee deems appropriate for achieving interoperability in the geodata and geoprocessing market. The AS may include data models, processing models, or other items necessary to implement the mission of the Technical Committee as defined by the OGC Planning Committee from time to time.

The detail of the Abstract Specification shall be sufficient to provide normative references, including models, and technical guidelines as a foundation for standards. Each standard, to the extent possible, will provide unambiguous normative and informative information that allows for implementation of standards in industry-standard software.

The level of detail of the AS is at the discretion of the Technical Committee as reflected by the actual content that is approved for inclusion in the document itself. The TC approves the content of the Abstract Specification.

There are two categories of potentially unacceptable Abstract Specification change proposals, including:

• Proposals that directly affect the content of an outstanding RFC (a decision made by the subgroup responsible for processing the proposed changes); and
• Proposals that affect the content of a completed RFC (these issues should be handled in the revision process because they potentially affect both the Abstract Specification and Implementation standards).

9.6.3 ISO Documents as OGC Abstract Specifications^[30]

A new AS Topic Volume or a revision to an existing AS Topic volume may be proposed by the OGC members for the case in which the document was created in an ISO TC 211 activity or a joint OGC and ISO TC 211 developed activity. There are the two cases: A document entirely developed in ISO and then recommended by OGC members to be an Abstract Specification and a document jointly developed by the OGC and ISO memberships. Each case is now described.

9.6.3.1 ISO Standard as an OGC Abstract Specification Topic Volume

For this case, the ISO Standard in question must be at FDIS (Final Draft International Standard) or published status.

• The ISO Standard is presented and discussed in an OGC Working Group.
• The WG Members determine that the ISO Standard should be a new OGC AS Topic Volume or should be a revision to an existing OGC AS Topic Volume.
• The WG makes a recommendation that the OGC TC should consider the motion to issue an adoption e-vote for the candidate Abstract Specification.
• The recommendation is presented to the TC for discussion - usually at an OGC face to face TC meeting.
• The TC can approve or not the recommendation to approve the adoption e-vote.
• A minimum three week review period is required prior to issuance of an adoption e-vote.
• The adoption e-vote is initiated and conducted as per the E-vote policy as defined in section 6.5 of this document.

for this case, the TCC will need to ensure that a copy of the ISO standard is freely available to the OGC Members for review. The request for the document can be made directly to the TC 211 Secretariat. The document shall then be posted to pending documents and the availability of the document announced to the Membership.

9.6.3.2 Joint OGC-ISO TC211 Standard as an OGC Abstract Specification Topic Volume

For this case, the OGC and ISO TC 211 have agreed to have a joint standards development activity. This decision is captured by approval by TC 211 of an official New Work Item Proposal (NWIP) and approval of an official OGC SWG Charter. The OGC SWG shall be open to participation by both OGC and ISO TC 211 members. The work of the SWG shall be under the OGC PnP for all activities related to the development and approval of an OGC standard. There will also be a parallel Edit Committee in TC 211 to process all of the ISO requirements for editing, review, and approval of an ISO Standard. The SWG Chair shall have responsibility of communicating and coordinating the joint activity.

9.7 Appeals Process

Appeals by any OGC member must be made before the OGC Architecture Board (OAB). Each appeal or issue will be taken on a case-by-case basis, but rulings made by the OAB with approval of the Planning Committee that affect the process will be reflected in these Policies and Procedures. If the member making the appeal is not satisfied by the decision made at the OAB level, the OGC Board of Directors may be presented with the case for final deliberation.

9.8 The Standard Revision Process

A primary function of a Standards Working Group (SWG) is to edit a candidate standard based on either a) comments received as part of the RFC process or b) the contents of one or more official OGC Change Request Proposal(s). If any member feels that a standard needs to be changed, edited, or enhanced, they must submit a Change Request Proposal.

All voting in a SWG, whether for processing a candidate standard or for revisions to an existing standard will follow the rules as defined in section 6.

9.8.1 The Revision Process

The SWG reviews requests for revisions and corrections to a standard. Requests for revisions must be in the form of comments received during any public review period, such as for the RFC process, or in the form of official Change Request Proposals (CRP). Ad-hoc emails and verbal requests at meetings will not be considered as official CRPs.  However, the SWG may vote to discuss issues that have not been submitted as CRPs, and may vote to direct one or more of its members to create official CRPs to document an agreement reached as the result of those discussions.

9.8.1.1 SWG Review of Change Proposals

As part of a revision process, the SWG processes change request proposals. Please refer to section 9.9 for additional policies and procedures related to change request proposals. Once a list of change proposals has been compiled and the SWG has discussed the proposed changes, the SWG voting members shall vote on the disposition of each of the proposed changes. The SWG has the right to reject a recommended revision, comment, or correction but must provide a written justification for the rejection.

Based on the outcome of the votes, SWG members then make the revisions and corrections to the target standard. Comments or CRPs received after the formation of a new SWG may or may not be considered for incorporation. This is at the discretion of the members of the SWG.

9.8.1.2 OAB Review and Public Comment

When the SWG work items are complete and with the approval of the voting members of the SWG, the new revised standard may be submitted to the OGC Architecture Board for a review and subsequent release for the 30 day public comment period.

From this point on, the processing of the revision to the standard is the same as defined in section 9.5.6.5 and subsequent sections.

9.8.2 Cut-off date for accepting new Change Request Proposals

Change Request Proposals (CRPs) to approved standard documents or documents currently in revision can be submitted at any time, and then must be considered by the appropriate SWG.  A SWG can set and publicize a cut-off date beyond which it will not consider additional CRPs.  CRPs submitted after such a cut-off date must be considered as part of future revision activities.

A cut-off date can be announced to the TC using the following rule:  That a cut-off takes effect the end of the next meeting after it has been announced. For example, an announcement at a June meeting would take effect at the next TC meeting, which is usually in September.

9.8.3 Additional Guidance and Responsibilities of a revision SWG

The SWG shall perform the following tasks.

• Develop a plan and schedule for completion of the new revision of the given standard. The Plan and Schedule, also known as a Road Map, will be made available to all OGC members as well as the Public.
• Work to insure that revisions to the standard are consistent and harmonized with other related OGC standards.
• Work to insure that the new revision is – as best as can be accomplished – backwards compatible with the previous revision.
• At completion of revisions to a standard and before the new version is voted on, provide a “release notes” document that describes all the changes to the standard. The revised standard will not be considered for adoption until this document is complete.
• Provide a revision notes document using the standard revisions template that documents the revisions to the standard resulting from either public comments or CRPs. The revision notes include lists of deprecated capabilities, changes to capabilities, and new capabilities that are added over time.
• Try to complete their work in a timely manner.
• Endeavor to reflect their perception of the consensus of the TC.

9.9 The Standard Editor

In addition to the formation of a SWG, there is a requirement for an editor or editors who will maintain the content of the candidate standard based on member input and the decisions of the SWG. One or more members can fill the Editor position. The Editor has the responsibility for managing the actual physical editing and maintenance of the standard document. The editor is neither the author, nor the owner of the document. By way of guidance, the Editor is responsible for:

• The editorial quality of the document: clear language, well written, self-consistent, and proper format;
• Ensuring that the consensus of the SWG and the TC  (approval of a CRP or edit and the language of the edit) is captured in the content of the document;
• Keeping modification of the document on schedule – knowing the content and history of the document well enough to prevent it from going around in circles, in an endless round of modification; and
• Maintaining a revision notes that document what changes were made and in response to which comments or CRPs. These notes will be used as the basis for creating the revision notes document for a given revision/version of a standard.

The Editor and the SWG Chair may or may not be the same individual.

9.10 Change Request Proposals to an OGC document

At any time, any OGC member or non-member can submit CRP. A CRP allows for the formal documentation of a proposed change to an existing, adopted OGC standard or abstract specification. The change could be an identified error (see section 9.11, Corrigendum Changes), an inconsistency, a requested enhancement, or a major proposed enhancement. Completed CRP’s shall be submitted on-line using the CR submission application on the OGC web site. Submitted CRP’s are catalogued and stored on a publicly accessible site.

The CR App URL is: http://www.opengeospatial.org/standards/cr

CRP’s are used as the basis for new SWG work items. The SWG will only consider proposed changes and enhancements to an adopted implementation that have been documented using the CRP template.

If a SWG does not exist for a given standard and there are CRP proposals for that standard, the TCC shall constitute a new SWG under the P&P outlined in section 7.7.

9.10.1 Submission of Change Request Proposals

Once a Change Request Proposal is completed, it shall be submitted to the OGC by posting to the Public Change Request page. If a CRP is to be discussed during a face to face SWG meeting, such as during a Technical Committee meeting, then change requests should be submitted to the CRP archive by the meeting 3 week rule. All CRPs shall be publicly available.

9.10.2 Evaluation of a Change Request Proposal

A CRP is processed by appropriate SWG. The SWG shall discuss the proposed CRP and then vote on how the CRP should be processed:

• Reject the CRP with a written reason;
• Accept the CRP but request additional clarification; or
• Accept the CRP with documentation as submitted.

If a CRP is accepted, the SWG will incorporate the contents of the CRP into the designated standard. If the CRP is rejected, then the SWG must write a formal response to the CRP submitter(s) explaining the rationale for rejection and then allow the submitter(s) the opportunity to respond and/or resubmit their CRP with modifications.

The disposition of any CRP will be noted on the pubic CRP web site.

9.10.3 Completion of a Change Request Proposal

When a SWG has processed a Change Request Proposal, the status of the CRP will be changed on the OGC CR archive. The status and disposition will be modified based on the SWG decisions. The CR will remain public and available for future reference. The normal procedure for this process is:

• At the completion of the work of the SWG, the SWG chair shall provide the TCC or his designee a list of completed change proposals; and
• The TCC or his designee shall update the status of those CRs on the OGC website.

9.11 Corrigendum (errata) Changes to OGC Standards

From time to time, members and the public will discover errors in a published and approved OGC standard. In such cases, a process is required to document and publish the corrections without forming a SWG^[31] and that follows the formal TC review and voting process. Under the corrigendum process, an error (or errors) in a published document discovered after adoption and publication is shown with its correction(s) under a separate sheet (or addendum). This process is very similar to the ISO Technical Corrigendum Process

This process operates as follows.

1. An identified error is documented and submitted to the OGC using the Corrigendum Proposal (CRP) template. The submitter(s) of the Corrigendum notify the TCC.
2. The TCC or designee evaluates to candidate corrigendum to verify that a specific error is being documented.
3. The TCC or designee communicates the documented error to the editor/author of the specified standard.
4. The editor/author checks the validity of the error and then communicates this information to the OGC membership for comment using standard OGC communications. The reason for the TC broadcast is that there may be many implementations of the standard for which an error has been documented.
5. If there is concurrence that the corrigendum documents a valid error, the editor/author writes the corrigendum and submits back to the TCC or his designee.
6. The Membership votes to release (or not) the error (deficiency) correction as a corrigendum. A Corrigendum vote will ask if there is any objection to unanimous consent. In order to speed the process, these votes will last for only two weeks and there is no IPR review requirement.
7. The corrigendum is published via OGC communications.

9.12 A Technical Amendment to an existing standard

From time to time there will be cases where it has been verified that an OGC standard is used, that it should continue to be made available, but that technical changes are needed, a deliverable may be proposed for amendment. An amendment alters and/or adds to an existing OGC standard. The determination as to whether one or more Change Request Proposal(s) result(s) in an Amendment or a complete revision shall be determined by the TCC in consultation with the Editor(s) of the standard. The OGC Architecture Board shall provide a final review and approval of a proposed amendment. By way of guidance, an amendment may consist of additional reference examples, use cases, schema changes, and other normative and informative content or clarifications.

Where it is decided that the OGC standard can be amended using the technical amendment process, an existing SWG may make the necessary edits without a Charter change.

An amendment will result in a new version number of the document. Further, as an amendment may contain both normative and informative changes, an electronic vote. However, a vote of the TC is required but may be done at a TC meeting or by e-vote.

9.13 Backwards Compatibility

In all cases of adopted standards in a revision process, the members will work to insure the highest level of achievable backwards compatibility to the previous release. In those cases in which backwards compatibility cannot be achieved, the SWG will insure that all inconsistencies are highlighted and documented. These will be incorporated into a Standard Revision Release set of notes that must accompany the new revision. Release notes document all enhancements, changes, and compatibility issues resulting from the revision of the interface standard. Both the TC and the PC reserve the right to review the issues related to backwards compatibility for a given revision of a standard. If the backwards compatibility issues are deemed too onerous, the TC and/or the PC may elect to reject the proposed revision.

10 Proprietary Rights, Copyrights, and Disclosure

10.1 Proprietary Rights[32]

During any meeting of the OGC Technical Committee or any subgroup of the TC, no participant shall disclose proprietary information. ^[33]

In addition, no information of a secret or proprietary nature shall be made available to the OGC as official documents, and no such documents (or documents marked as such) shall be made OGC official documents or forwarded to the membership.

All proprietary information that may nonetheless be disclosed by any participant during any meeting of the TC or any subgroup of the TC shall be deemed to have been disclosed on a non-confidential basis, without any restrictions on use by anyone (except that no valid copyright or patent right shall be deemed to have been waived by such disclosure).

10.2 Copyrights

All proposals intended to affect the contents of  OGC standards, once submitted to the TC, (a) convey sufficient royalty free license rights to OGC to permit it to publish, license and sublicense the same freely to all third parties, and to permit OGC and all such third parties to own any derivative works base thereon without financial obligation to the submitter, but (b) do not in any way indicate that the submitter has surrendered or waived any copyright or patent in such proposal.

10.3 Disclosure

It is the policy of the TC that the all pending proposals and documents shall be restricted to member internal distribution. The exceptions are:

• Change Requests Proposals. All CRPs shall be made public; and
• When an external standards organization requires access to a members’ only document. The TCC, after due consideration and dialogue with the members, may determine that a given document can be shared with the external standards organization.

11 TC Planning Committee Representatives

11.1 Role and Responsibilities

As stated in the Bylaws of the OGC, the OGC TC has the right to seat two representatives on the OGC PC. Up to seven representatives may be available in a “pool” and the TCC will work with the representatives to choose the two to attend a specific PC meeting. This section details the role and responsibilities of these individuals and the process for their election.

The role of a TC Representative to the PC is to bring issues of concern to the general TC membership to the attention of the PC and to keep the TC apprised of the activity of the PC. Responsibilities of the representatives include the following:

• Accept documented issues from TC members and bring these forward at PC meetings;
• Provide a report to the TC of the activities that take place at PC meetings no later than two weeks following a PC meeting;
• Be involved in discussions related to the ongoing work and issues in the TC; and
• Vote.

11.2 Elections

The election of these representatives will be held according to the following rules.

• Nominations will be made from the ranks of Voting TC Members (an individual or an individual representing an organization already holding a seat on the PC cannot be nominated).
• There must be at least one nominee for each vacancy.
• The nomination must be accepted by the nominee.
• Each Voting TC Member may vote for one candidate per vacancy to be filled.
• Up to seven representatives may be elected, from which no more than two can attend any PC meeting.
• The representatives will be selected in the order of most votes received to fill the available positions.

11.3 Term of Office

The term of office for TC representatives to the PC shall be as recommended by the TC with a maximum term of two years. In the case of resignation, removal, death, or termination of TC Membership of a representative, the rules for election will be invoked to fill the vacancy. Also, the TCC may determine that a given TC representative to the PC is not fulfilling their obligations, such as not attending PC meetings on a regular basis. For example, if the TC representative misses two or more meetings in a row. In such a case, the TCC may ask the TC representative to resign and the rules for election will be invoked to fill the vacancy.

12 Temporarily Overriding Specified Procedures

The Technical Committee may temporarily override specific procedures set forth in this document by a specific motion to override the normal TC Policies and Procedures. Approval of such an override motion shall require a two-thirds majority vote of non-abstaining Voting TC Members, present at a quorate TC meeting or by electronic TC vote

13 Adoption of This Policy Document

In order to be accepted or modified, this document must be ratified by a two-thirds (2/3) vote (under the rules herein) at a TC meeting, electronic, or via electronic vote. Changes to this document are to be presented to the TC, included in the meeting’s minutes, and ratified by the same procedure. Meetings in which a vote on acceptance or modification of this document is to occur must include the change in the published agenda for the meeting. Alternatively, the OGC PC can make changes to these Policies and Procedures by its normal operational process.

Annex A: Terms and Definitions

AP (Application Profile) -Set of one or more base standards and - where applicable - the identification of chosen clauses, classes, subsets, options and parameters of those base standards that are necessary for accomplishing a particular function [ISO 19101, ISO 19106]

Application Schema: [ISO 19109] An application schema utilizes an Implementation standard and adds application specific entities, e.g., feature types. An example of an application schema is InDoorGML or CityGML.

AS (Abstract Specification): A document (or set of documents) containing an OGC consensus computing technology independent specification for application programming interfaces and related specifications based on object-oriented or other IT accepted concepts that describes and/or models an application environment for interoperable geoprocessing and geospatial data and services products.

BOD: (Board of Directors): Defined by the bylaws of the OGC.

BP (Best Practice Document):A document containing discussion of best practices related to the use and/or implementation of an adopted OGC document or related technology and for release to the public. Best Practices Papers are the official position of the OGC and thus represent an endorsement of the content of the paper.

Candidate standard: An engineering document that describes an existing, operational standard that one or more OGC Voting TC Members wish to sponsor as an RFC submission under the Bylaws of the OGC.

Deprecated Document: An official standard of the OGC but no longer maintained. An OGC document shall be deprecated by a vote of the OGC Voting Members, usually as part of a standards adoption vote.

ER (Engineering Report):An ER Report is a document that reports on some technical activity in an Interoperability Program Initiative. An ER Report may also be a candidate standard or a formal change request proposal for an approved standard. An ER Report documents are submitted to the OGC TC for review and comment. An ER Report is not a publicly available document unless approved for release by the OGC membership. An ER Report does not represent the official position of the OGC nor of the OGC Technical Committee.

Invited Guest:A liaison representative appointed by an external organization which has reciprocal liaison status with the OGC, or an individual who has received an invitation to attend meetings of the TC. The OGC staff or Voting TC Members may issue invitations. It is the policy of the OGC to freely allow guests and observers, so long as they provide a request to attend to the OGC staff and pay the appropriate meeting fees.

IP (OGC Interoperability Program):A global, collaborative, hands-on engineering and testing program designed to deliver proven candidate standards into the OGC Standard Development Program and to exercise and test existing OGC standards in domain specific situations. More information about the IP can be found at www.opengeospatial.org/initiatives.

IPR (Intellectual Property Rights): An umbrella term used to refer to the object of a variety of laws, including patent law, copyright law, trademark law, trade secret law, industrial design law, and potentially others.

Issues:Issues are questions (other than standard adoption questions) that come before the Technical Committee for discussion, resolution and, potentially, final recommendation to the PC.

Items: Items are proposed standard adoption questions that come before the committee for discussion, resolution and, potentially, final recommendation to the PC. Items come about through TC voting membership motions and seconds, typically in response to RFCs, PC directives, and WG recommendations, or the normal course of TC business.

Necessary Claims:Those claims of a patent or patent application, throughout the world, excluding design patents and design registrations, Owned by a Member or its Related Parties now or at any future time and which would be Necessarily Infringed by implementation of a standard.  Notwithstanding the foregoing, Licensed Claims shall not include any claims  (i) relating to any enabling technologies that may be necessary to make or use any implementation of a standard but are not themselves expressly set forth in the standard (e.g., semiconductor manufacturing technology, compiler technology, object oriented technology, basic operating system technology, and the like); or (iii) necessary for the implementation of other published standards developed elsewhere and merely referred to in the body of the standard. For purposes of this definition, a standard shall be deemed to include only architectural and interconnection requirements essential for interoperability and shall not include any implementation examples unless such implementation examples are expressly identified as being required for compliance with the standard.

OGC-Open Geospatial Consortium Founded in 1994, the OGC is a voluntary consensus standards organization.

OAB (OGC Architecture Board) - The OGC Architecture Board works with the TC and the PC to insure architecture consistency of the Baseline and provide guidance to the OGC membership to insure strong life cycle management of the OGC standards baseline.

OGC Communication:A communication by any means, including posting on the WWW Site (http://www.opengeospatial.org), electronic mail, facsimile transmission, or by regular post. The primary forms of communication will be either via email or using the OGC Members Only Portal. Any member desiring delivery by other than electronic means (WWW site or electronic mail) must state so in written form to OGC staff.

OGC standard: A document containing an OGC consensus computing technology dependent standard for application programming interfaces and related standards based on the Abstract Specification or domain-specific extensions to the Abstract Specification provided by domain experts.

OGC Member, or Member: Any member in good standing.

OGC Member Portal: A members’ only accessible component of the OGC web site. The Portal provides a location for storing and accessing all in progress OGC TC and PC documents, all WG agendas, working documents, and presentations, and to perform project management functions, such as tasks, tracking actions, and calendars.

OGC Standards Program:Provides an industry consensus process to plan, review and officially adopt OGC Standards for interfaces and protocols that enable interoperable geoprocessing services, data, and applications. The OGC bodies involved in the Standard Program are the Technical Committee, Planning Committee, and Strategic Member Advisory Committee.

Profile: [ISO 19109]A profile is a strict subset of a standard applicable to multiple Application Schemas. An example of a profile is the GML Simple Feature Profile.

PC (Planning Committee)-The OGC Planning Committee is granted authority to operate by the OGC Bylaws. Principal Membership is available for organizations that wish to participate in the planning and management of the Consortium’s technology development process.

RAND: Reasonable and Non-discriminatory.

Request for Comment, or RFC (See Section 9.4):An explicit request to the industry for comments concerning a particular candidate standard that a Standards Working Group is considering for adoption as a standard satisfying a portion of the Abstract Specification. An RFC begins as an unsolicited proposal from a Voting TC Member or members and results, if successful, in an OGC standard. The RFC process is typically how interface and encoding standards developed in the OGC Interoperability Program move into the formal OGC TC standards approval process.

Retired Document:An OGC document that, by Member approval, is no longer an official or supported document of the OGC. As such, retired documents should not be referenced in any procurement, policy statement, or other OGC document. Retired documents are made available on the OGC website for historical purposes.

SAC (Strategic Member Advisory Committee):The SMAC is granted authority to operate by the OGC by-laws. The SMAC has as a primary responsibility to recommend areas of strategic opportunity for Consortium operations and recommending resource strategies in support of Consortium programs to the Board of Directors, Consortium staff and the Membership.

Standards Development Process: The operational details of the discussing and evaluating technologies relevant to the OGC standards baseline, standard revision, and the RFC processes to propose, review, recommend modifications to, and recommend adoption of candidate standards.

Standards Baseline: The complete set of member approved abstract specifications, standards and best practices documents.

TC (Technical Committee) See Section 5:The OGC TC has been granted authority to operate by the OGC Bylaws.  The OGC Technical Committee is composed of individuals representing organizations that are duly recognized members in good standing of the OGC. 

TC Member:Any member in good standing of the TC.

Voting TC Member:Any member of the TC who may vote on TC Items and Issues. Voting TC Members are the Technical Representatives of OGC Technical Committee Members, Principal Members, and Strategic Members. Only the designated Technical Representative from a given member organization may be a Voting TC Member.

WP (White Paper):An OGC member approved publication released by the OGC to the Public that states a position on one or more technical or other subject that is germane to the work of the OGC, often including a high-level explanation of a standards based architecture or framework of a solution. A White Paper often explains the results or conclusions of research. A White Paper is not an official position of the OGC.

Annex B: RFC Process Outline: Full OGC Standard

The following are the steps required for the RFC process.

• RFC Submitter(s) contact TCC or his designee by normal OGC communications about their desire to submit a candidate standard.
• RFC submitters commit to having considered the OGC standards baseline in the development of their submission. Any deviations or differences are noted and documented. If the OGC Abstract Specification is impacted, these impacts are noted and documented.
• RFC submitters provide to the OGC a Candidate standard (CS). The CS is accompanied by several other documents, as described in the RFC process. This bundle of documents is called an RFC Proposal. The Candidate standard can be the result of work performed in an OGC Interoperability Initiative and documented in an IP Report. The RFC proposal package is submitted to the TCC or his designee and includes:
• A cover letter that specifies the commitment of the organization to support the candidate standard submission.
• If required, a signed OGC SUBMISSION OF TECHNOLOGY FORM (This can be found at www.opengeospatial.org/legal).
• Any evidence of implementation for the CS. Prototypes and demonstration implementations are fine
• The CS. This is the actual document defining the standard and must be provided in the appropriate OGC standard template format. This template can be found on the OGC web site or can be provided by the TCC or his designee.
• The TCC or his designee notifies the TC of the availability of a new RFC submission package.
• The submission team develops a charter for a new SWG and announced to the TC. The team shall submit the charter to the TCC for review.
• A SWG is formed and a call to the TC membership is made. Member representatives can opt-in or not to work on the candidate standard.
• The SWG votes as to whether the CS should be released for public comment.
• The OAB reviews the candidate standard. Any OGC names (http uri’s) are submitted to the OGC Naming Authority for review and approval.
• The announcement is for public comment using normal OGC Communications and the CS along with instructions is posted to the Public section of the OGC web site.
• Industry responds to the Request by submitting comments (these are delivered to the TC and to the RFC submitters). This comment period typically lasts 30 days. All comments must be provided to the OGC through the formal mechanism described at the time of RFC release.
• At the end of the comment period, all comments are packaged and sent to the SWG.
• If required, the SWG will then modify the Candidate standard and resubmit it along with a Response to the Comments back to the TCC or his designee. The SWG will need to modify the Candidate standard if:
• A comment identifies an error in the candidate standard;
• A comment identifies an inconsistency in the candidate standard that makes it non-functional;
• A comment identifies a major inconsistency in the candidate standard that “breaks” interoperability with existing adopted OGC standards.
• Once all comments have been processed and the necessary changes made to the standard, the SWG votes to recommend to the TC for an IPR review and concurrent e-vote for adoption.
• The candidate standard is presented to the TC either in a Plenary meeting or via video and/or web conference.
• The TC votes to start and electronic vote to recommend approval of the standard.
• The TC votes to recommend to the PC to adopt and 60 day IPR review period begins.

Upon successful TC recommendation vote, the PC votes to adopt the standard.

Annex C - Community Standard

C.1 Qualification Checklist – Community Standards

The following is a list of questions that the submission team needs to answer in the affirmative prior to submitting community specification into the OGC.

1. Does the submission team understand that copyright and intellectual property (PR) shall be vested or shared with the OGC? Note: If the plan is to move the document to Provisional or Full standard status, all IP shall be vested to the OGC.
2. Does the submission team understand that if the candidate standard is approved as an OGC standard that life-cycle governance shall be vested with the OGC[1]?
3. Is there sufficient evidence of broad implementation?
4. Is the candidate standard unencumbered by any 3^rd party intellectual property?
5. Is there method to determine compliance with the community standard? This could be an abstract test suite, a compliance test framework, clearly defined requirements, or other text in the document that describes compliance.

C.2 Community Standard Process Checklist

[1] Please note that for external standards brought into the OGC, such as KML, the external community is still able to develop, test, and document new functionality and changes to the standard. This is per the OGC Best Practice “KML – Standard Development Best Practices” [OGC 08-125]. Once the external community is ready, these changes shall be documented and submitted into the OGC using the OGC Change Request Process