-
Notifications
You must be signed in to change notification settings - Fork 13
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.
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
Isolating the Data Model from the Interfaces #35
Comments
From a layering perspective, separating them makes a lot of sense. IMO the only advantage to having them combined at this stage is for convenience (for those of us iterating on both), but they could be split up at any time, and they'd most likely need to be split up before progressing to standards track. Switching the interface to non-normative / commentary is an interesting idea that could address the convenience factor -- if that's really a concern. So strong support on isolating. No strong preference on how that's accomplished -- splitting vs commentary -- will go with popular opinion on that. |
This keeps coming up. IMO splitting the spec is not necessary especially if the conformance section establishes conformance can be to the data model and /or the interfaces... it amounts to the same thing. I am hesitant to split a spec we are already seeing little contribution too, but I am in favor of trying to adapt thee interfaces section to be more general / supportive of Aries controller interfaces. |
I am going to close this issue, I've gotten a lot of feedback that folks like the interfaces, and splitting the spec is extra work for the editors.... We can decide to split the sections up if and when this spec graduates from the ccg. |
In discussion on the Aries WG B Call 20201008, several opinions were voiced about the separation of concerns between use of the data model as a backup/restore/portability mechanism and the abstract interfaces present in the same spec. Some of the opinions offered included that the spec as an interoperability effort should not have concerns with the internal functions of the software using the data model, and that those interfaces were not an external integration point anyway.
Two options were discussed to rectify the problem: Splitting the interface section into a separate spec, or include the interfaces as commentary in a non-normative assumptions manner.
Is there support for isolating the data model from the interface section?
The text was updated successfully, but these errors were encountered: