3.3.1.  Domain Working Group

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

• Have a formal approved charter that defines the DWGs Scope of Work and estimated timeline for completion of the work (if applicable);

• Provide a forum for discussion and documentation of interoperability requirements for a given information or user community;

• Provide a forum to discuss and recommend document actions related to Interoperability Program Reports;

• Develop Change Request Proposals (CRPs) for existing OGC standards;

• Develop Engineering Reports with the intent seeking approval by the TC for release of these documents as OGC White Papers, Discussion Papers or Best Practices Papers;

• Informational presentations and discussions about the market use of adopted OGC standards.;

• Have all-member voting policies (unless otherwise stated); and

• Have missions and goals defined by the TC.

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

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

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

Specific work items for a SWG could be:

• Have a formal approved charter that defines the SWGs Scope of Work and estimated timeline for completion of the work;

• Develop a new candidate standard in preparation of that document as an RFC submission.

• Process a new RFC submission candidate standard once approved by the OAB;

• Consider official Change Request Proposals to an existing OGC standard and make changes to the standard as necessary: from this perspective, a SWG does all the work that was formerly performed by a Revision Working Group;

• Approve a candidate standard for public comment;

• To vote on any changes to a candidate standard or to an existing OGC standard; and/or

• Make recommendations to the entire TC once a document is ready for a formal adoption vote;

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

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.3.1.  Votes that can occur at a TC DWG Face to Face Meeting

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

The votes that may occur at a DWG are:

• Move to release an Engineering Report as a Discussion Paper;

• Move to initiate an electronic vote to release an Engineering Report or other OGC document as a Best Practices document;

• Move to elevate a Discussion Paper to a Best Practices document;

• Move to recommend to the TC a change in policy or procedure;

• Move to accept or revise a DWG charter;

• Move to dissolve a DWG; and

• Move to modify the charter of a DWG.

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

5.3.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 1 — Vote types and allowed voters

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

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

Often the following clause is added:

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

5.3.4.  Proxy for Voting

Not every OGC TC Voting member can attend every TC Closing 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 or in written form. The written proxy form is 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. Assignment of proxy to another full-time employee of the Voting member’s organization may be communicated verbally to the TCC in advance of or at the TC Closing Plenary.

Proxy shall be communicated to the TCC in advance of the TC Closing Plenary. 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.”

5.4.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 Clause 5.4.6). The start and end dates for any given vote are set by OGC staff and are posted with the ballot and announced.

5.4.2.  Continuity

Except for the following reasons, an electronic vote shall remain open for the duration as stated in Clause 5.4.1:

• A WG withdraws the motion to approve a candidate standard (see Clause 5.4.9); or

• The TCC, the OAB, or the WG identifies a procedural error and requests the vote be stopped.

5.4.3.  Eligibility

All Voting TC Members 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.

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

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

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

5.4.7.  Approval

In addition to Sufficiency thresholds, for documents that are official OGC positions, such as a standard, creation of a new WG, 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

5.4.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. For a standard adoption vote, then the SWG shall respond in writing to all comments within 30 days of the completion of the vote. For other votes, 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 Clause 5.4.9) then no response to comments is required.

5.4.9.  Withdrawal

A motion may only be withdrawn by the Working Group (except for votes initiated by the TCC, such as the election of OAB members) that made the original motion or by the TCC for procedural reasons. 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.

5.4.10.  Restarting a vote

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

• If a WG withdrew a motion and there is no content change to the document, the WG can at any time request the TCC initiate new vote.

• If a WG withdrew a motion and the content of the document is changed, then the WG needs to restart the approval process (in the case of a RFC: OAB review, public comment, vote).

• If the vote was stopped for procedural problem(s), fix the problem(s), and initiate a new vote.

• If failure to approve the motion (See Approval and Sufficiency), then the appropriate OGC group needs to address all comments, revise the document and restart the RFC approval process with an OAB review, public comment, final edits to the document and a new adoption vote.

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

5.4.12.  Visibility

The following rules relate to transparency of the voting process.

• During and after a vote, individual votes and comments are visible to any OGC member during and after the voting period.

• After the vote is complete, the public only sees the vote result and does not see how an Eligible Voter voted or commented.

• The WG can vote to make public the comments and WG responses to the comments — but shall not provide the name of the Voter who made a given comment.

5.4.13.  Assuming Successful TC vote, what next?

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

• The TCC shall announce the results of the vote.

• If there are any comments, the submission team or SWG shall respond to all comments submitted during the voting period. The responses to the comments shall be documented in an OGC document that is then posted to pending.

• The TCC shall make a recommendation to the Planning Committee requesting approval of the motion from the Technical Committee. The PC shall have two weeks to consider the motion, ask questions, and approve or reject the motion. Approval in the PC is a simple majority of the PC members.

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

6.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 at OGC Portal Templates.

6.5.3.  Approval of a Sub-Group Charter

Once the Charter is completed and agreed to by the members of the Ad-hoc, the following process if followed for approval of the Charter.

• The charter is reviewed by the TCC. The TCC shall provide edits and comments in a timely manner.

• The ad-hoc considers the TCC comments and edits the charter as necessary.

• The charter is assigned an OGC document number and posted to pending documents.

• The availability of the draft charter is announced to the TC and to the public and a three-week public review period begins. There is a formal press release with a general call for comments.

• If possible, the draft charter is presented to the TC at a plenary. Otherwise, a PowerPoint or video presentation will be developed and posted to the Portal. NOTE: For a SWG, this document or video should cover the key aspects of the charter, especially the scope of work, the timeline, and the technical discussion related how the standards work aligns with the current OGC standards baseline.

• Comments received during the comment period are considered by the ad-hoc members and any necessary changes to the draft charter are completed.

• The modified charter is posted to pending as an update with a new revision number. The TCC shall notify the membership that a revision of the charter has been posted.

6.5.4.  Changes to a WG Charter or Recharter of a WG

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 will then assess if the changes are a natural progression of the work of the WG or a major shift in scope of the WG.

• If the TCC judges the changes to reflect a natural progression of the WG work, then the TCC shall notify the full membership of the proposed changes. 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 at a Closing Plenary or through an email vote.

• If the TCC judges the changes to reflect a major shift in scope of the WG, then the revised charter shall proceed through the same approval process as a new WG charter in Clause 6.5.3.

• When the recharter vote is requested to start to the TC, the TC has the option to override the TCC vote type recommendation. For instance, if the TCC recommends a vote at the Closing Plenary, the TC can demand instead that a full 45-day electronic vote be held because the TC feels the scope of the revised charter is too different from the original charter.

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

6.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 OGC Portal Templates.

6.7.2.  “Charter” members of the SWG

The charter members for a SWG will be:

• Any members that are part of an RFC submission team;

• Any member who asks to join the SWG during the three-week SWG Charter review period; and

• Any members who participate in the development of the Charter for a new SWG.

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

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

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.

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.

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

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

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

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

6.7.8.  Responsibilities of the SWG Chair and Co-Chair

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

• Ensuring that minutes of meetings are taken, and once approved by the SWG voting members and made available electronically to the SWG membership within two weeks of the meeting. Minutes must include:

  • A list of persons attending the meeting and determining if there is quorum;

  • A list of motions, seconds, and outcomes; and

  • A section that details specific actions taken by members of the subgroup.

• Reporting on subgroup activities to the TC and if the SWG meetings during a TC meeting, presenting at the closing TC Plenary, including presenting subgroup recommendations (if any). Any reports to the TC SHALL be approved for release by the SWG voting members.

• Maintaining SWG member status on the Portal (voting, observer, etc).

• Ensuring that issues are logged into the Portal and these issues are prioritized and put into a roadmap for completion of a revision (or a future revision). Further, that the Chair ensures that the pertinent standard roadmap is updated, agreed by consensus of the SWG members, and posted at least for each regularly scheduled TC meeting time.

• Ensuring that issues worked result in official change proposals and that only these official change proposals shall be considered by the SWG.

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

6.7.9.  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 that quorum is 1/2 of active voting members (see Clause 6.7.10) unless the SWG votes to have a larger fraction be quorum. See Clause 5.5 for electronic 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.

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

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

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

6.7.11.  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, to another standards organization, or to the public for comment. Such an action requires a formal SWG motion and SWG vote as per Clause 6.7.9.

6.7.12.  Umbrella SWGs

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

• All affected SWGs shall vote to agree to participate in the umbrella SWG;

• All affected SWGs shall have the same IPR policy; and

• The existing charters for the affected SWGs shall be updated to state that the SWG is part of an umbrella SWG.

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

7.6.1.  Submission of documents to be considered as an OGC Best Practice

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

• Evidence of implementation. Evidence of implementation shall include but not be limited to: Implementation in commercial product, implementation in open source applications or software, and/or implementation in deployed applications. A single research related implementation is not proper evidence of implementation.

• An Abstract or Introduction in the document explaining why a submitted document is relevant to the OGC.

• Presentation of the contents of the proposed BP at an OGC face-to-face meeting. The presentation may be done remotely using OGC communication tools, such as GoToMeeting.

• Post the document to OGC Pending Documents on the OGC Members Portal for at least three weeks prior to the face-to-face presentation.

7.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 (Clause 5.4).

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 OGC Policy Directives, Clause 7.

7.7.1.  Document Numbers

All member submitted documents shall be assigned a document number. Members can obtain pending document numbers using the members only Portal, OGC Pending Documents page located at OGC Portal Home.

Instructions for obtaining a Pending Document number and posting the document can be found at OGC Portal Instructions.

7.7.2.  Document version numbers

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

• All non-specification/standards documents do not have version numbers at publication.

• Only approved OGC standards have document numbers 1.0.0 or greater. The first approved version of an OGC standard shall be version 1.0.0.

• Corrigendum releases shall NOT result in any change to the major/minor number. If the standard being revised has schema, then the schema shall use the version attribute to document the revision number at the third level.

• Revisions to an adopted standard typically result in a change to the minor number. For example, the first revision to an adopted 1.0 standard would be 1.1.0. Minor revision releases should be 100% backwards compatible with the previous version.

• Changes to the major version number are reserved for when there are significant changes to the adopted standard or when backwards compatibility cannot be maintained with the previous version.

See also OGC Policy Directives, Clause 18.

7.7.3.  Change Proposal Format

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

7.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 TC 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” (OGC Portal Home).

The TC will enforce this policy under the conditions described for the Clause 5.2.

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

• Microsoft Word including .docx format (preferred),

  NOTE  Microsoft provides conversion tools for backwards compatibility.

• Rich Text Format (RTF),

• Portable Document Format (PDF),

• Hypertext Markup Language (HTML),

• Microsoft PowerPoint (preferred for presentations),

• Microsoft Excel (preferred for tabular information such as lists of URLs),

• AsciiDoc, or

• ASCII Text.

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

8.2.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 Clause 8.4.7.

8.4.1.  Conditions for Submission of an RFC

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

• Three different Member organizations endorse the submission.

• A Voting Member is the lead for the submission team.

• For a candidate Community standard or a candidate standard with Compliance Suite there is evidence of implementation and evidence of a continued commitment to commercialize and/or support the implementation.

• For a Community standard, the submission team completes a written justification as to why the Community standard track is being requested. This step is described in more detail below.

• All required documents (see below) must be ready for submission to the OGC for consideration through a Request for Comment (RFC) process.

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

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

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

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

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

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

8.4.6.  Main Steps in the RFC Process

The steps in the OGC RFC Process are as follows.

8.4.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 the Clause 8.2.1. The candidate standard with Compliance Suite must then proceed with the OAB Review (Clause 8.4.6.4) through Voting (Clause 8.4.6.9) steps.

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

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 Clause 8.4.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.

8.5.1.  Authoritative Standards Development Organization

An Authoritative SDO is an organization which operates on a consensus basis to develop standards and which has been designated to be an Authoritative SDO by the PC. An Authoritative SDO develops key foundational standards which provide a basis for conceptual and implementation standards created by the OGC. These foundational standards may be approved to be part of the OGC Abstract Specification. A list of Authoritative SDOs shall be maintained by the Standards Program. ISO is already considered to be an Authoritative SDO.

The Authoritative SDO shall be notified if one of its Standards is proposed by the OGC to be a Topic of the Abstract Specification. The Authoritative SDO shall have the opportunity to reject the OGC proposal, in which case the Authoritative SDO Standard may still be used as a normative reference by other OGC standards, but will not be a part of the OGC Abstract Specification. There is no requirement that the Authoritative SDO provide its Standard to the OGC by any basis other than the normal distribution mechanism for the Authoritative SDO, although provision of the standard for no fee is preferred.

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

8.5.3.  Authoritative SDO Documents as OGC Abstract Specifications

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 Authoritative SDO activity or a joint OGC and Authoritative SDO-developed activity. There are the two cases: A document entirely developed in the Authoritative SDO and then recommended by OGC members to be an Abstract Specification and a document jointly developed by the OGC and Authoritative SDO memberships. Each case is now described.

8.8.1.  Submission of Change Request Proposals

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

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

8.8.3.  Completion of a Change Request Proposal

When a SWG has processed a CRP, the status of the CRP will be changed on the OGC CRP archive. The status and disposition will be modified based on the SWG decisions. The CRP 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.

8.9.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 CRPs. 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.

8.9.2.  Cut-off date for accepting new 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.

8.9.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 ensure that revisions to the standard are consistent and harmonized with other related OGC standards.

• Work to ensure 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.