Replaced by Newer Version



 

1     Abstract

The OGC provides 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:

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 (PC). These policies and procedures may be augmented or clarified by Policy Directives issued and approved by the TC or the PC. Such directives are databased and hyperlinked to/from the appropriate portion of this document.

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     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:

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

3     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:

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:

 

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:

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 OGC Architecture Board (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     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 three primary subgroups: the OGC Naming Authority, Working Groups (WG), and Subcommittees (SC) to:

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.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.1   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.

A SC may be proposed by any TC member. The TCC shall determine whether the SC should be established and whether a charter is necessary. The TCC will then request approval of the SC by a PC vote (face to face or two-week electronic vote).

4.2   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.2.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:

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.2.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.7for details on the policies and procedures for SWGs. The following is a general overview.

Specific work items for a SWG could be:

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.

SWGs are persistent unless the SWG voting members decide otherwise and choose to  dissolve the SWG once they have completed their work as described in their charter or choose to end the work.

5     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.

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.

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. The TCC will maintain a master agenda that is available to members and which is generated from the agendas of each WG as they are populated.

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 three weeks 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.

6     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 where votes are to occur to ensure 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 an electronic or 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:

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.

 

Table
Vote Type Who can Vote

Approval of a White Paper, Discussion Paper, or Engineering Report

Any member

Election of TC reps to the PC

Any member

Approval of a DWG Charter

Any member

Approval of deprecation or retirement of Discussion Paper or Best Practice

Any member

Approval to start electronic vote for an OGC Best Practices Document

TC Voting Member

Approval to start electronic vote for adoption of an OGC standard

TC Voting Member

Approval to start electronic vote for a revision of an OGC standard

TC Voting Member

Approval to start electronic vote for a new TC P&P or other policy document

TC Voting Member

Approval to start electronic vote for a new SWG or Community standard work activity

TC Voting Member

 

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 to recommend <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.

Proxies are not transitive: that is, if Member A holds a proxy for Member B and Member B holds a proxy for Member C, Member A can only vote on behalf of Member B and CANNOT further vote on behalf of Member C by “proxy to a proxy.”

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:

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):

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 1/3 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 or more 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.

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.

6.5.13                  Assuming Successful TC vote, what next?

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

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:

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 (see 7.7.11) 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 any time 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     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.

7.2   Role of Subgroup Chairs

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

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:

 

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).

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.

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:

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 section 7.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

7.7.2     “Charter” members of the SWG

The charter members for a SWG will be:

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.

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. Quorum is 1/2 of active voting members unless the SWG votes to have a larger fraction be quorum. 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 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:

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     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 in Word format from: http://portal.opengeospatial.org/index.php?m=public&subtab=templates&tab=2 or which is available in the OGC GitHub repository as a series of AsciiDoc files.

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

WGs and SCs shall often be used to hear presentations in their interest area. Further, a WG or SC can generate Discussion Papers for the industry covering a specific technology area germane to the WG’s or SC’s interest area. In either case, the WG or SC 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 WG or SC 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 WG at an OGC TC face-to-face meeting. The WG 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 WG 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.

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 WG 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 athttps://portal.opengeospatial.org/index.php?m=public&orderby=Manage&tab=1.

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

8.7.2    Document version numbers

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

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:

8.7.5    Policy for the Retiring, Deprecating, or Rescinding OGC Documents

This section provides the policy and procedure for retiring, deprecating, or rescinding OGC documents. Note that retiring, deprecating, or rescinding an OGC standard results in the same fate for all extensions to that standard; such a fate is version-dependent: only the extensions specific to the exact version of the standard being retired, deprecated, or rescinded will share that fate. Deprecation of a standard does not automatically result in the deprecation of a profile of that standard.

8.7.5.1     Retiring OGC Documents

“Retirement” criteria can be based on one or more of the following:

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.

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.

8.7.5.2     Deprecating OGC standards

OGC policy documents may be deprecated by vote of the TC. A deprecated document is no longer supported, but is made available to the public on the OGC website and other resources.

8.7.5.3     Rescinding OGC standards

OGC standards may be rescinded for three reasons:

  1.   The standard includes intellectual property that was illegally provided as part of the standard;
  2.   A Community standard is abandoned by its originating/maintaining party and the OGC membership does not take-over maintenance of that Community standard; or
  3.   A Community standard is judged by OGC membership to no longer be applicable to the OGC Mission.

A standard is rescinded by electronic vote of the TC as described in Section 8.7.5.

9     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 adoption votes to approve a document as an OGC standard shall 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 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.

 

SWG

Evidence of Implmentation

Modular Spec

Compliance Test

OGC Template

Public Comment

OAB Review

IPR to OGC

Member Vote

Community standard

NR*

Strong

NR*

Partial

Yes

Yes

Yes

Yes or Shared

Yes

Full Standard Track

 

standard

Yes

No

Yes

NR*

Yes

Yes

Yes

Yes

Yes

standard with Compliance Suite

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

*NR - Not required.

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 date 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.

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-113r1, 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.5.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 internal review and Public Comment (All)

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.

Full standard: Once the SWG determines that the candidate standard is ready for OAB and OGC-NA 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.

Community standard: The community standard submission team and the TCC must agree that the candidate standard is ready for review and the TCC will submit the candidate standard for internal review by the OAB and OGC-NA.

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. The candidate standard cannot be released for public comment until it is approved for release by the OAB. The OAB may request changes to be made to the candidate standard and have that document returned to the OAB for further review.

9.5.6.5     Review of OGC Identifiers (http URIs, 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.

NOTE: the team cannot accept a comment that makes a normative change to a Community standard unless the comment identifies an error. A Community standard is normatively-frozen once it enters the approval process.

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).

If the RFC comments result in a significant change to the candidate standard, then the TCC may request that the revised candidate standard be reviewed by the OAB once more prior to the TC adoption vote.

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 Policies 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.5.8    Specific policies regarding profiles moving from a Best Practice to a standard

In the case where an OGC-approved Best Practice is a profile of an active standard (i.e., not retired, deprecated, nor rescinded) and members wish to submit the profile for adoption as a full standard, the standard approval process is modified as follows.

NOTE: if the Best Practice is a profile combined from multiple standards, then the profile must be advanced as a standard via the normal full standards track process. The single standard to which the profile applies may itself have normative references to other standards; such a situation does not make the profile “combined from multiple standards.”

1.     The submitters of the Best Practice must agree to proceed with the standard adoption process.

2.     The SWG responsible for the parent standard (i.e., the standard to which the profile applies) must vote to proceed with the standard adoption process per the normal SWG processes and voting rules.

3.     The candidate standard is reviewed by the OAB and the OGC-NA.

4.     The candidate standard will be assessed against the same criteria applied to the parent standard. For instance, if the parent standard was approved prior to publication of the Modular Specification, then the candidate standards will not be required to be compliant with the Modular Specification.

5.     The candidate standard is released for a 30-day simultaneous TC and public request for comment.

6.     Comments are reviewed and addressed by the submitters to the satisfaction of the TCC.

7.     The candidate standard is voted upon by the TC and PC per Section 9.5.6.9. Note that the Best Practice was already approved by the TC and PC, so a presentation to and request to start a vote from the TC will not be required.

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.2    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.2.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.

NOTE: 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.2.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 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.9   Change Request Proposals (CRP) to an OGC document

At any time, any OGC member or non-member can submit a 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://ogc.standardstracker.org/

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.9.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.9.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, either as a revision or a corrigendum. 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.9.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.10  The Standard Revision Process (Full Standard)

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.10.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.10.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.10.1.2  Internal 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 OAB and OGC-NA 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.10.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.10.3                  Additional Guidance and Responsibilities of a SWG during the revision process

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.11  Corrigendum (errata) Changes to OGC Standards (Full Standard)

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  Backwards Compatibility (Full Standard)

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. The OAB performs review of every standard proposed for adoption by the OGC. The OAB is an entity organized under the Consortium.

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

Full standard: Process Checklist Responsible

Contact Technical Committee chair about intent to submit or start

Convener and TCC

Identify submission team (3 or more Members, one is TC Voting Member)

Convener

Signed Submission of Technology form (optional)

TCC and convener

TC Chair says great, write SWG Charter

TCC

Submission Team writes draft Standards Working Group Charter

Submission Team

When draft ready, the team sends the draft to the TCC

Convener

TC Chair reviews draft and provides comments back to the submission team

TCC

Submission Team reviews TCC comments and modifies charter as required

Submission Team

When ready, convener posts draft charter to pending documents.

Convener

After posting, the TCC shall notify the membership of the draft

TCC

30 day public comment and review period

45 day TC approval vote

Members

OGC Portal Update

Staff

Press release to announce formation of new SWG

Staff and Submission team

TCC does a call for participation (always open)

TCC

SWG officially starts. First order of business is to elect chair etc

SWG

Call for Change Requests (optional)

SWG

    Call for CR's - Press Release (optional)

Staff and SWG

Work on candidate standard happens

SWG

    For a revision to an existing standard, collate all CR's and prepare summary

SWG

    For a revision to an existing standard, process all CR's

SWG

Editor(s) edit the document based on change requests

Editor(s)

Release for public comment

SWG and TCC

    Notify TCC of intent for release for public comment

SWG Chair and TCC

    Develop Press release and make OGC web site updates

SWG and Staff

    OGC Architecture Board Review

OAB

    OGC Naming Authority Review

OGC-NA

    Post to SWG portal project as a public read access document

SWG Chair and editor

30 day public comment period

Community

The SWG Compiles a list of the comments into a document

SWG

SWG Processes the public comments.

SWG

Editor(s) edit the document based on comments

Editor(s)

For a revision, write release notes

SWG

SWG Briefs TC Membership on contents of candidate standard

SWG Chair or designee

SWG Votes to release candidate standard for adoption vote

SWG

SWG Chair tells TC Chair the result of the SWG Vote

SWG Chair and TCC

TCC reviews candidate standard and makes suggestions

TCC

SWG Posts candidate standard to pending documents.

SWG Chair

TCC Announces adoption vote

TCC and Staff

45 day adoption vote happens

Voting Members

Vote completes

Announcement to OGC Members

TCC

Planning Committee Approval

TCC and PC

SWG process any comments reveived during the adoption vote

SWG

SWG updates Change Request status for each CR processed

SWG

Confirm list of contributors

TCC and SWG Chair

TCC does final review of adopted standard

TCC 

Create Press release to announce new standard

SWG and OGC staff

Schema processing

SWG and OGC staff

    Schemas validated and errors corrected

SWG and OGC staff

Standard published

OGC staff

Update PURL server for new spec artefacts

OGC-NA and Staff

Press release released

OGC staff

Done. Congratulations!!

 

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 3rd 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

Community Specification: Process Checklist Responsible

Contact Technical Committee chair about intent to submit or start a community spec process

Convener and TCC

Identify submission team (3 or more Members, one is TC Voting Member)

Convener

Signed Submission of Technology form (optional)

TCC and convener

TC Chair says great, provide justification.

TCC

When draft ready, the team sends the draft to the TCC

Convener

TC Chair reviews draft and provides comments back to the submission team

TCC

Submission Team reviews TCC comments and modifies justification as required

Submission Team

When ready, convener posts draft justification document to pending documents.

Convener

Two week review period. Comments can be provided.

Members

TC Chair asks TC if there are any objections to accept community spec into OGC process

TCC and members

Concurrently, TC Voting members have formal vote to bring community spec into the OGC process

TCC and TC voting members

Press release to announce formation of new OGC activity

Staff and Submission team

Any edits on candidate standard happen. Normative content may not change

Team

Approval process for public comment

Team Chair and TCC

    Develop Press release and make OGC web site updates

Team and Staff

    OGC Architecture Board Review

OAB

    OGC Naming Authority Review

OGC-NA

30 day public comment period

Community

The Submission team consolidates the comments into a single document

Team

Submission Team reviews comments and modifies document as required

Team

Team Briefs TC Membership on contents of candidate standard

Team Chair or designee

TCC reviews candidate specification and makes suggestions

TCC

Team Posts candidate specification (can be HTML, Word, ZIP).

Team Chair

TCC Announces adoption vote

TCC and Staff

45 day adoption vote happens

Voting Members

Vote completes

Announcement of results to OGC Members

TCC

Planning Committee Approval

TCC and PC

Team process any comments received during the adoption vote

Team

Confirm list of contributors

TCC and Team Chair

TCC does final review of adopted standard

TCC 

Create Press release to announce new standard

Team and OGC staff

Schema processing

Team and OGC staff

    Schemas validated and errors corrected

Team and OGC staff

Standard published

OGC staff

Update PURL server for new spec artefacts

OGC-NA and Staff

Press release released

OGC staff

Done. Congratulations!!

 

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

 

[1] As defined in ISO/IEC Directives, Part 2

[2] http://www.nist.gov/standardsgov/omba119.cfm

[3] OGC standards are member approved interface and encoding engineering specifications developed via the OGC Consensus process that are publicly and openly available for use in the geospatial and IT community.

[4] http://www.opengeospatial.org/ogc/policies/conduct

[5] Proposals as used here is meant to be a general term to cover RFCs, Discussion Papers, Best Practices, and Engineering Reports.

[6] http://http://www.robertsrules.com/ Robert’s Rules of Order, Eleventh Edition, 2011.

[7] In order to ensure that business moves along, voting by proxy is allowed, duly noting the dangers of voting without physical proximity. We feel that the notification requirements for the different phases of technology sponsorship sufficiently protect member organizations from adoption without due ability to oppose.

[8] The total of Strategic, Principal, Technical, and Technical Aggregate Members

[9] NOTE: All approved OGC Technical Committee document or policy recommendations are then presented as a recommendation to the OGC Planning Committee (PC). The PC shall review the recommendation and either approve the recommendation as is, ask the TC for clarification, or in very few instances not approve the recommendation and ask the TC to provide clarifications or more require more work on the document.

[10] Except for votes initiated by the TCC, such as the election of OAB members.

[11] Even if the meeting where the motion is made has a quorum, and thus could cast a legal vote, the membership may delay the meeting for some period to allow for research into issues that may affect their votes. Under RONR, a motion to “Postpone the motion to a certain time” would be appropriate (see RONR, 11th Edition, §14, page 179). The limits on such a motion applies, such as the postponement cannot be beyond the end of the next scheduled meeting, and certain motions cannot be postponed (adjournment for example) and must be voted on in their normal order.

RONR allows such procedures in the absence of a quorum under the “measures to obtain a quorum.”

[12] In the past, some groups have not met for a considerable time and are no longer active. The existence of these groups can be misleading to those trying to understand what OGC is currently doing. This proposal suggests a mechanism for reviewing subgroups, and taking some action when appropriate. This will help ensure the groups in OGC are aligned with the actual work being done within the TC.

[13] For a Standards Working Group (SWG) charter, the ad-hoc is the submission team.

[14] It was felt that WGs should be able to use all of the expertise at hand in arriving at recommendations. All TC member organizations could be represented (and vote) at WG meetings in order to allow the expression of all members’ opinions. OGC Voting TC Members are protected from control by non-voting members by virtue of the fact that WGs may only form recommendations to the TC and not final TC votes. WG minutes are also available to all members of the TC, so that other TC members may understand and accept or reject WG recommendations.

[15] Reasonable and non-discriminatory

[16] While there is not a formal requirement for a Community standard to use the OGC document template for a standard the OGC encourages the Candidate standard submission team to consider using the OGC document template.

[17] Typically, official documents are provided to the public in Word “.doc” format or Adobe PDF format. However, various presentations, draft documents, and so forth can also be distributed in PowerPoint format, HTML, and other formats as provided by the Members. The TCC reserves the right to reject a document that is in a non-industry standard distribution format.

[18] Initial publications in 2014.

[19] Microsoft provides conversion tools for backwards compatibility.

[20] If a standards document is retired, any associated Best Practice document shall automatically be retired,

[21] It is felt that this most important TC vote should encompass the entire Voting TC membership, rather than a portion of a meeting quorum, to allow all OGC Voting TC Members to have control over the issue. Note that the TCC does   not cast a vote in the specification adoption process as the TCC vote may only be used in the case of a tie. Under the rules of the new OGC IPR policy, all Specification votes will be by electronic vote. As such, the entire TC voting membership will have the opportunity to vote.

[22] It was felt that it is not within the TC’s purview to determine the ability or intent of an OGC member and technology sponsor to commercialize a technology. However, it was felt that the TC’s work would be fruitless without such ability and intent. Therefore, recommendations to the PC shall implicitly or explicitly include such caveats.

[23] If a candidate standard is developed entirely within the OGC process, then a SoT is not required.

[24] The Specification Model - A Standard for Modular specifications (08-131r3)

[25] This information is to be provided in the Community Standard Justification document. A Community standard is not required to align with the current OGC standards baseline or may overlap existing OGC standards functionality.

[26] http://portal.opengeospatial.org/files/?artifact_id=40077

[27] As specified in OGC 09-046, 09-047, and 09-048 (latest versions) found at http://www.opengeospatial.org/ogc/policies/directives

[28] http://purl.oclc.org/docs/index.html

[29] The SWG may determine that a longer comment period is required.

[30] Please refer to the ISO-OGC Terms of Reference for details of the working relationship between the OGC and ISO TC 211 - Geomatics. https://portal.opengeospatial.org/files/?artifact_id=69074.

[31] The members may determine that a SWG should be formed to properly discuss the necessary changes to correct the deficiencies. In this case, the SWG Revision P&P will be followed.

[32] Please read the OGC IPR Policy documents located at www.opengeospatial.org/legal for the complete text and description of the OGC IPR policy. If at any time there is confusion or conflict between what is stated in the TC P&P and the OGC IPR Policy, the OGC IPR Policy takes precedent.

[33] This section clearly places the onus of protection of proprietary rights on the owner of those rights. No discussion of proprietary technology can take place during a TC or TC subgroup meeting, protecting the participants in the meeting from accidental exposure to proprietary information (and consequent future legal problems with that participant’s own intellectual property rights). If a TC member wishes to present information of a proprietary nature to members of the TC, he or she may arrange a meeting of the interested parties totally separate from the TC process and meeting.