feat(proposal): expand SDK support with a native Go SDK

[jpower432]

Description

Project Alignment and Scope

This proposal outlines the development of a native Go SDK to complement the Python SDK and extend support for OSCAL to cloud native applications developed in Go.

Linked Issues

Prior proposal that relates to this #68

Additional Considerations

• I volunteer to maintain the proposed project and help facilitate cross-language collaboration

[jpower432]

/vote

[git-vote]

Vote created

@jpower432 has called for a vote on feat(proposal): expand SDK support with a native Go SDK (#83).

The members of the following teams have binding votes:

Team
@oscal-compass/oversight-committee-members

Non-binding votes are also appreciated as a sign of support!

How to vote

You can cast your vote by reacting to this comment. The following reactions are supported:

In favor	Against	Abstain
👍	👎	👀

Please note that voting for multiple options is not allowed and those votes won't be counted.

The vote will be open for 28days. It will pass if at least 51% of the users with binding votes vote In favor 👍. Once it's closed, results will be published here as a new comment.

[vikas-agarwal76]

@jpower432 Need to understand how we will try to maintain functional parity between GO and Python SDK as per the proposal document. Will the GO SDK have same / similar API as the python SDK or something else? If yes, then should we wait till we have the Python SDK interface defined.

[jpower432]

@vikas-agarwal76 Yes, would be to have a similar API to the Python SDK. My goal here was to capture the details at a high level to gauge community interest and once it was understood whether this was supported by the community get more detailed on the implementation.

However, I have added more details to the Testing Plan section to help support from a decision making perspective. Let me know if that helps clarify my ideas on testing approaches. If needed, I can also link some projects that we can look to as examples.

If yes, then should we wait till we have the Python SDK interface defined.

I don't disagree with this. That is why I linked this as a future milestone in proposal #68. However, given the phased approach being taken there, I think if could align on the common logic and use the initial Python SDK for prototyping, these two projects could probably be further developed in parallel.

[jpower432]

/check-vote

[git-vote]

Vote status

So far 85.71% of the users with binding vote are in favor (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
6	0	0	1

Binding votes (6)

User	Vote	Timestamp
ancatri	In favor	2024-09-24 13:25:39.0 +00:00:00
yuji-watanabe-jp	In favor	2024-09-24 13:24:48.0 +00:00:00
jflowers	In favor	2024-09-19 16:44:14.0 +00:00:00
jpower432	In favor	2024-09-19 20:58:06.0 +00:00:00
mrgadgil	In favor	2024-09-24 13:22:44.0 +00:00:00
vikas-agarwal76	In favor	2024-09-24 13:24:35.0 +00:00:00
@degenaro	Pending

Non-binding votes (1)

User	Vote	Timestamp
rahearn	In favor	2024-09-19 17:40:18.0 +00:00:00

[git-vote]

Vote closed

The vote passed! 🎉

85.71% of the users with binding vote were in favor (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
6	0	0	1

Binding votes (6)

User	Vote	Timestamp
@jpower432	In favor	2024-09-19 20:58:06.0 +00:00:00
@ancatri	In favor	2024-09-24 13:25:39.0 +00:00:00
@jflowers	In favor	2024-09-19 16:44:14.0 +00:00:00
@mrgadgil	In favor	2024-09-24 13:22:44.0 +00:00:00
@yuji-watanabe-jp	In favor	2024-09-24 13:24:48.0 +00:00:00
@vikas-agarwal76	In favor	2024-09-24 13:24:35.0 +00:00:00

Non-binding votes (1)

User	Vote	Timestamp
@rahearn	In favor	2024-09-19 17:40:18.0 +00:00:00

[jpower432]

Based on the results of this vote, repository https://github.com/oscal-compass/oscal-sdk-go has been created. The contents of the proposal itself can still be altered if PR reviewers have feedback.

[jflowers]

LGTM