Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

One of the factors contributing to the success of the OGC APIs is that the standards are purposely written to be “developer friendly”. This means that the standards are written to leverage existing tooling (e.g. OpenAPI, OpenLayers) and existing Web standards that are maintained outside the OGC. An implication of this is that OGC standards sometimes have to make accommodations for the tooling or standards. The question then arises to what extent such accommodations should be made especially when they lead to what some SWG members might consider sub-optimal design. #265

Open
ogcscotts opened this issue Jun 12, 2023 · 1 comment
Open

One of the factors contributing to the success of the OGC APIs is that the standards are purposely written to be “developer friendly”. This means that the standards are written to leverage existing tooling (e.g. OpenAPI, OpenLayers) and existing Web standards that are maintained outside the OGC. An implication of this is that OGC standards sometimes have to make accommodations for the tooling or standards. The question then arises to what extent such accommodations should be made especially when they lead to what some SWG members might consider sub-optimal design. #265

ogcscotts opened this issue Jun 12, 2023 · 1 comment

Comments

@ogcscotts
Copy link
Owner

No description provided.

@ogcscotts
Copy link
Owner Author

From the Closing Plenary discussion on 8 June 2023

Platform dependence and "sub-optimality": this is why we work towards standard concepts from which to optimize concrete implementations with some interoperability
Optimality depends on your objective function (:>)

example of ARML 2.0 - worked for a market at the time that completely disappeared... do we always design for "now?"

the market decides what succeeds. If our compromises are useful for the market that is good.

optimality is subjective

OGC members once built all of the geospatial implementations, now there are many non-geospatial players

the Standard may be developed based on things in the market, but some Standards are trying to influence the market

OGC seems like it might have an institutional answer to this issue - it would seem very important for Standards to reflect usage (vs computationally optimal, etc) while the COSI program is well-designed to "Show the Way" to better solutions, no?

need to do more outreach to the developer (commercial and open source) communities with more precise roadmapping

so maybe we do a better job of highlighting issues that need market input in the process, not just burying them in Github issues

this is marketing of our Standards; marketing those Standards as solutions to market needs... but we may be developing Standards for which there is no market

we are working toward developer-friendly content, but what about management-friendly: a summary of use cases right up front

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@ogcscotts