You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The normal usage pattern for the library is to use the static JsonLdProcessor class. This works well for the stateless, static algorithms which make up the JSON-LD standard. However, it requires a consumer to create an injectable facade class in order to inject the APIs into consumers. e.g.
Can we provide the functionality exposed by JsonLdProcessor as a non-static implementation of an interface which can be mocked for purposes of unit testing / decoration.
The text was updated successfully, but these errors were encountered:
This interface would require a dependency on Json.NET, so I would prefer a signature that only dealt with objects we defined in our own Core. Something like this:
This would make the Core to be dependency-free and allow Json.NET, System.Text.Json, Turtle, and possibly other serializations as ancillary projects to the Core.
Agreed. I was not proposing an exact interface here. I also think that we should allow that #66 and #65 might be implemented in either order since we are evolving the codebase
This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.
The normal usage pattern for the library is to use the static JsonLdProcessor class. This works well for the stateless, static algorithms which make up the JSON-LD standard. However, it requires a consumer to create an injectable facade class in order to inject the APIs into consumers. e.g.
Can we provide the functionality exposed by JsonLdProcessor as a non-static implementation of an interface which can be mocked for purposes of unit testing / decoration.
The text was updated successfully, but these errors were encountered: