Compatibility with existing implementations

[tomhgmns]

I notice that the draft charter of the working group contains the following paragraph:

"When possible, the Solid Protocol will evolve while maintaining a high degree of compatibility with existing implementations, of both servers and clients, and with features from prior versions. If incompatible changes have to be made, then they will be done by introducing a stage where both old and new protocols are supported, to allow the implementors to upgrade their systems in a managed way."

I'm worried because I know for a fact that Inrupt doesn’t follow the Solid draft specification (e.g. the Interop Spec) and implements something completely different to achieve the same outcome (see e.g. these "Enterprise" Solid Server docs).

As the Advisory Committee Representative of Digita, I'm wondering what this would this mean for the standardisation process...

I propose to remove this paragraph.

[csarven]

The quoted text is about the Solid Protocol. I'm not sure I understand the relevancy of the Solid Application Interoperability specification (and/or other specifications) and a particular party not implementing them.

My reading of the text is that a gradual evolution in the ecosystem without major disturbances is promised (or intended). While the paragraph outlines a plan with good intentions, I wouldn't raise an objection to removing it in that it may need not be stated in the charter.

As for the standardisation process, here are some initial considerations (I may add more later):

• The WG will need to further describe the upgrade stage in any case - I suspect as one of the earliest issues - and have it be covered by the conformance model.

• The Success Criteria states:

  In order to advance to Proposed Recommendation, at least two independent interoperable implementations of every feature [..] and two or more implementations interoperating with each other".

  The upgrade stage would be for the prior Maturity Levels and based on Semantic Versioning.

• The upgrade stage may slow things down from the standardisation perspective - making specification releases - but has the benefit of not leaving implementers behind or potentially leaving users of their products dissatisfied. Things will work (tm).

• The current active Process https://www.w3.org/2021/Process-20211102/#Votes states the following which would become relevant when breaking change are proposed and voting may be necessary:

  In order to vote to resolve a substantive issue [..e]ach organization represented in the group must have at most one vote, even when the organization is represented by several participants in the group (including Invited Experts).

Do you have an objection to keeping that paragraph in now (or may later)?

Would you like certain clarity either as a future participant in the WG?

Do you have concerns as an implementer?

[elf-pavlik]

IMO we should clarify what the existing implementations have to conform to be considered, for example, Solid Protocol v0.11

This would make it clear anything implemented that goes outside of it doesn't get considered with the same criteria as what conforms specifically to Solid Protocol v0.11

[timbl]

I think the text is important because for example, for people joining the WG that haven't been involved in the CG before, to point out to them that this The Solid Protocol 0.x has been running for years. Gentle process bug fixes and incremental improvement. Large changes wouldn't be appropriate. As you said for interoperable implementations. The stability of that is important for the whole ecosystem. This applies to the Solid Protocol.

The "Solid App Interop" Spec is NOT at this level at all, does not have consensus, and has IMPO lots of problems, and no one should be criticised for not implementing it.

[pchampin]

It seems obvious to me that "existing implementations" refer to implementation of the spec as it is published by the CG. It is the responsibility of the CG to determine the compliance criteria for its spec, and my understanding is that some efforts have been put into this already.

The sentence is important, because it prevents the WG from going into a totally different direction and breaking the existing ecosystem as a whole. I does not apply to any single implementation that would do its own thing.

[csarven]

Closing as per 2023-06-07 agreement https://github.com/solid/specification/blob/main/meetings/2023-06-07.md#compatibility-with-existing-implementations in that there was no objection to keeping the paragraph in.