PROPOSED Spatial Data on the Web Working Group + Charter
+ +The mission of the Spatial Data on the Web + Working Group is to: + +
-
+
- develop and maintain vocabularies and best practices that + encourage better sharing of spatial data on the Web; + +
- identify areas where standards should be developed jointly by both W3C and the Open Geospatial Consortium + (OGC). +
This proposed + charter is available on GitHub. Feel free to raise issues. + +
| Charter Status + + | See the group + status page and detailed + change history. + + |
|---|---|
| Start date + + | [dd monthname yyyy] (date of the + "Call for Participation", when the charter is + approved) + + |
| End date + + | [dd monthname yyyy] (Start date + + 2 years) + + |
| Chairs + + | [chair name] (affiliation) + + |
| Team Contacts + + | Bert Bos + (0.1 FTE) + + |
| Meeting Schedule + + | Teleconferences: weekly? + Face-to-face: during + the W3C's annual Technical Plenary week; additional + face-to-face meetings may be scheduled by consent of + the participants, usually no more than 3 per year. + |
Motivation and Background
+ +Background of landscape, technology, and + relationship to the Web, users, developers, implementers, and + industry. +
Scope
+ +The Spatial Data on the Web WG will: + +
-
+
- Create and maintain geospatial Web standards and + geospatial profiles of more general standards as enumerated + in deliverables. + +
- Coordinate among incubation groups, by providing a forum + where early ideas for geospatial Web standards can be + shared, identifying ideas for further standardisation by + W3C and/or OGC, and making recommendations about these + incubations to the relevant standards body or bodies. + Related incubation will generally happen in W3C Community + Groups and OGC Innovation Program initiatives. + +
- Respond to requests from OGC Architecture Board (OAB) + and W3C Technical Architecture Group (TAG) to review + materials relating to Geospatial Web standards, and + proactively bring relevant matters to the attention of the + OAB and TAG. + +
- Periodically review and amend the OGC Technology Trends, + OGC Innovation Program ideas issue tracker and W3C strategic incubation pipeline ("funnel") to + identify, prioritise and track important ideas relating to + geospatial Web standards. +
Out of Scope
+ +The following features are out of scope, and will not be + addressed by this Working group. + +
-
+
- The Spatial Data on the Web Working Group will only + produce deliverables where it is in the interests of both + OGC and W3C to collaborate. +
Deliverables
+ +Updated document status is available on the group + publication status page. + +
Draft state indicates the state of the deliverable
+ at the time of the charter approval. Expected
+ completion indicates when the deliverable is projected
+ to become a Recommendation, or otherwise reach a stable
+ state.
+
+ The Working Group will deliver the following W3C
+ normative specifications:
+
+ Consider making a second list for existing
+ specifications that the group will maintain.
+
+ Other non-normative documents may be created such as:
+
+ Put here a timeline view of all deliverables.
+
+ Normative Specifications
+
+
+
+
+
+
+
+
+ Other Deliverables
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Timeline
+
+
+
+
Success Criteria
+ +In order to advance to Proposed Recommendation, each normative specification is expected to have at least two independent interoperable implementations + of every feature defined in the specification, where + interoperability can be verified by passing open test suites, + and two or more implementations interoperating with each + other. + +
There should be testing plans for each specification, + starting from the earliest drafts. + +
Consider adopting a healthy testing + policy, such as: To promote interoperability, all + changes made to specifications in Candidate Recommendation or + to features that have deployed implementations should have tests. Testing efforts should be conducted via the Web + Platform Tests project.
+ +Each specification should contain sections detailing all + known security and privacy implications for implementers, Web + authors, and end users. + +
For specifications of technologies that + directly impact user experience, such as content + technologies, as well as protocols and APIs which impact + content: Each specification should contain a section on + accessibility that describes the benefits and impacts, + including ways specification features can be used to address + them, and recommendations for maximising accessibility in + implementations.
+ +This Working Group expects to follow the TAG Web Platform + Design Principles.
+ +Consider adding this clause if the Group + does not intend to move to REC: All new features + should have expressions of interest from at least two + potential implementors before being incorporated in the + specification. +
Coordination
+ +For all specifications, this Working Group will seek horizontal review for accessibility, + internationalization, privacy, and security with the relevant + Working and Interest Groups, and with the TAG. + Invitation for review must be issued during each major + standards-track document transition, including FPWD. The Working + Group is encouraged to engage collaboratively with the + horizontal review groups throughout development of each + specification. The Working Group is advised to seek a review + at least 3 months before first entering CR and is encouraged + to proactively notify the horizontal review groups when major + changes occur in a specification following a review. + +
Additional technical coordination with the following Groups + will be made, per the W3C + Process Document: + +
In addition to the above catch-all reference to
+ horizontal review which includes accessibility review, please
+ check with chairs and staff contacts of the Accessible Platform
+ Architectures Working Group to determine if an
+ additional liaison statement with more specific information
+ about concrete review issues is needed in the list below.
+
+ Check this list
+
+ Most working groups operating at OGC have a scope that
+ may intersect with topics of interest discussed in the
+ Spatial Data on the Web Working Group. The OGC Architecture
+ Board (OAB), comparable to the W3C Technical Advisory Group
+ (TAG) will provide high level guidance to the Spatial Data
+ on the Web Working Group. The Working Group expects to
+ liaise with OGC groups as needed, and more specifically
+ with:
+
+ W3C Groups
+
+
+
+ OGC Groups
+
+
+
+ External Organizations
+
+
+
+
Participation
+ +To be successful, this Working) Group is expected to have 6 + or more active participants for its duration, including + representatives from the key implementors of this + specification, and active Editors and Test Leads for each + specification. The Chairs, specification Editors, and Test + Leads are expected to contribute half of a working day per + week towards the Working Group. There is no minimum + requirement for other Participants. + +
The group encourages questions, comments and issues on its + public mailing lists and document repositories, as described + in Communication. + +
The group also welcomes non-Members to contribute technical + submissions for consideration upon their agreement to the + terms of the W3C + Patent Policy. + +
Participants in the group are required (by the W3C Process) to follow the W3C Code of Ethics + and Professional Conduct. +
Communication
+ +Technical discussions for this Working Group are + conducted in public: the meeting minutes from teleconference and + face-to-face meetings will be archived for public review, and + technical discussions and issue tracking will be conducted in + a manner that can be both read and written to by the general + public. Working Drafts and Editor's Drafts of specifications + will be developed in public repositories and may permit + direct public contribution requests. The meetings themselves + are not open to public participation, however. + +
Information about the group (including details about + deliverables, issues, actions, status, participants, and + meetings) will be available from the Spatial Data on the Web + Working Group home page. + +
Most Spatial Data on the Web Working Group teleconferences + will focus on discussion of particular specifications, and + will be conducted on an as-needed basis. + +
This group primarily conducts its technical work pick one, or both, as appropriate: on the + public mailing list public-sdw-wg@w3.org (archive) or on GitHub issues. The public is invited to review, discuss + and contribute to this work. + +
The group may use a Member-confidential mailing list for + administrative purposes and, at the discretion of the Chairs + and members of the group, for member-only discussions in + special cases when a participant requests such a discussion. +
Decision Policy
+ +This group will seek to make decisions through consensus + and due process, per the W3C + Process Document (section 5.2.1, Consensus). Typically, + an editor or other participant makes an initial proposal, + which is then refined in discussion with members of the group + and other reviewers, and consensus emerges with little formal + voting being required. + +
However, if a decision is necessary for timely progress + and consensus is not achieved after careful consideration of + the range of views presented, the Chairs may call for a group + vote and record a decision along with any objections. + +
To afford asynchronous decisions and organizational + deliberation, any resolution (including publication + decisions) taken in a face-to-face meeting or teleconference + will be considered provisional. A call for consensus (CfC) + will be issued for all resolutions (for example, via email, + GitHub issue or web-based survey), with a response period + from one week to 10 working days, depending on the chair's + evaluation of the group consensus on the issue. If no + objections are raised by the end of the response period, the + resolution will be considered to have consensus as a + resolution of the Working Group. + +
All decisions made by the group should be considered + resolved unless and until new information becomes available + or unless reopened at the discretion of the Chairs. + +
This charter is written in accordance with the W3C + Process Document (Section 5.2.3, Deciding by Vote) and + includes no voting procedures beyond what the Process + Document requires. +
Patent Policy
+ +This Working Group operates under the W3C + Patent Policy (Version of 15 September 2020). To promote + the widest adoption of Web standards, W3C seeks to issue Web + specifications that can be implemented, according to this + policy, on a Royalty-Free basis. For more information about + disclosure obligations for this group, please see the licensing + information. +
Licensing
+ +This Working Group will use the W3C Software and Document license for all its + deliverables, with copyright held by OGC and W3C. Published + documents will be clearly marked as joint deliverables. +
About this Charter
+ + This charter has been created according to section 3.4 of the Process
+ Document. In the event of a conflict between this
+ document or the provisions of any charter and the W3C
+ Process, the W3C Process shall take precedence.
+
+ Note:Display this table and update
+ it when appropriate. Requirements for charter extension
+ history are documented in the Charter Guidebook (section 4).
+
+ The following table lists details of all changes from the
+ initial charter, per the W3C Process Document (section 4.3, Advisory Committee
+ Review of a Charter):
+
+ [description of change to charter,
+ with link to new deliverable item in charter] Note: use the class Changes to this document are documented in this section. Charter History
+
+
+
+
+
+
+ Charter Period
+
+ Start Date
+
+ End Date
+
+ Changes
+
+
+ Initial charter
+
+ 19 October 2021
+
+ 04 October 2023
+
+
+
+
+ Extension
+
+ 04 October 2023
+
+ 04 April 2024
+
+
+
+
+ Rechartered
+
+ [dd monthname yyyy]
+
+ [dd monthname yyyy]
+
+
+ new for
+ all new deliverables, for ease of recognition.
+ Change log
+
+