Strategy for normative references

[elf-pavlik]

We discussed this issue already twice during our meetings on 2023-03-08 and 2023-04-19.

Based on our conclusions the Normative References are required to be at most one maturity level behind the specification depending on them. After closing #28 where we also discussed it:

Normative references in Solid Protocol, Version 0.10.0, that do not have a FPWD or later status at W3C:

• Solid-OIDC (Solid CG)
• WAC (Solid CG)
• ACP (Solid CG)
• Solid Notifications Protocol (Solid CG)
• WebID (WebID CG)
• N3 (Notation 3 CG)

As per Version 0.10.0, the Solid WG will have to work with the Solid, WebID, and Notation 3 CGs to ensure that those normative references are progressed as well.

In the most recent draft, we have this statement in https://solid.github.io/solid-wg-charter/charter/#dependencies

Depending on the W3C Solid Community Group progress, including consideration for adequate implementation experience, the Group will also produce W3C Recommendations for the following documents:

• Solid-OpenID
  Allows entities to authenticate within the Solid ecosystem.
• Web Access Control
  Web Access Control (WAC) is a decentralized cross-domain access control system providing a way for Linked Data systems to set authorization conditions on HTTP resources using the Access Control List (ACL) model.
• Access Control Policy
  Access Control Policy (ACP) is a language for describing, controlling, and granting access to resources.
• Solid Notifications Protocol
• Linked Data-based protocol for sending notification to client application upon updates to resources in the Solid ecosystem while respecting resource-based access controls and privacy.

Since Solid CG can NOT directly advance any document on the REC track, I don't see how WG can depend on the CG for ensuring that Normative Dependencies will be at the required maturity level.

As I mentioned before only two options seem to be available to meet the requirement for normative dependencies:

1. Adopt all the documents expected to be a normative dependency as WG work items and set expectations on progressing them on the REC track.
2. Redesign the specification so that it does NOT have normative dependence on the specifications left in CG, we discussed it and this would most likely result in the solid protocol missing some key aspects.

[pchampin]

As I mentioned before only two options seem to be available to meet the requirement for normative dependencies:

1. Adopt all the documents expected to be a normative dependency as WG work items and set expectations on progressing them on the REC track.

2. Redesign the specification so that it does NOT have normative dependence on the specifications left in CG, we discussed it and this would most likely result in the solid protocol missing some key aspects.

I concur with this analysis, but in my view the current wording addresses this :

• it leaves the door open for option 1 ("Depending on ..., the group will produce W3C recommendations")
• but of course option 2 still on the table (as the only way forward if the conditions on option 1 are not met)

[elf-pavlik]

If there is consensus that Solid Protocol can be published without some/all of those dependencies I think we can close this issue. To my understanding, @timbl wanted the AuthN and AuthZ to get covered, which means that the Solid Protocol would require Solid-OIDC together with WAC and ACP.

Unless we can resolve it throughout the week we could try to address it during the next meeting.

---

The current, charter explicitly lists WebID and linked data formats (I would imagine N3 fits under it) as out of scope. Besides the drafts that are being worked on by the CG, and which could be adopted, I think the Solid Protocol will not be able to have a normative dependency on WebID and N3.

Should we mark both as 'at risk' and already signal in the Solid Protocol draft, which is being submitted to the proposed Solid WG, that it will not depend on WebID and N3?

[csarven]

The CG's conclusion was to seek W3C's guidance on how to approach dependencies and maturity levels. Once again, we neither have sufficient information or authority to make the call.

Moreover ( #28 (comment) ):

[S]ome of the normatively referenced IETF specifications may need to have a more mature status.
Other normatively referenced specifications include the Fetch specification by WHATWG which has the Living Standard status.

Naturally the Solid CG can't advance specs out of its purview but the feedback we need from W3C is clarity on normative references and their maturity levels in the case of Solid Protocol. Essentially additional advisory on https://www.w3.org/2021/Process-20211102/#transition-reqs :

For a First Public Working Draft there is no “previous maturity level”, so many requirements do not apply, and approval is normally fairly automatic. For later stages, especially transition to Candidate or Proposed Recommendation, there is usually a formal review meeting to ensure the requirements have been met before approval is given.

Going forward, it would be useful to get TAG ( #15 ) and AB's input on this, possibly in addition to Director. If AC okays the charter, then everyone is on the same page about the expectations, and to reduce the chances of a possibility of a Formal Objection in this regard.

[csarven]

The current, charter explicitly lists WebID and linked data formats (I would imagine N3 fits under it) as out of scope.

The Out of Scope section is about the kind of features or work items that won't be taken on by the WG. It currently indicates identity mechanism and data formats, and WebID, DID, and Linked Data formats as examples. So, the WG won't start or continue a work item - or possibly at least on a Rec track - to deliver things like "SolidId" or Solid DID Method or RDFa 1.2 or Liquid Data Format. Ditto no new mime types. Solid Protocol's current use of N3 is not a new format.

Having said that, some of limitations like that can be lifted with re-chartering but it'd be better for the WG to offload those kind of work items to dedicated CGs/WGs and then reference them if so required.

Again, the Scope section needs a rewrite: #9

[elf-pavlik]

Having said that, some of limitations like that can be lifted with re-chartering but it'd be better for the WG to offload those kind of work items to dedicated CGs/WGs and then reference them if so required.

If WebID or N3 is to be used as Normative Reference, having a CG working on it doesn't really help since they can't take them through the REC track. AFAIK there is no WG committing to delivering WebID or N3 specifications, which means we should plan the Solid WG deliverables in a way that doesn't expect any of those two as a Normative Reference.

---

The CG's conclusion was to seek W3C's guidance on how to approach dependencies and maturity levels. Once again, we neither have sufficient information nor authority to make the call.

Given the guidance we have received so far, I think we should just assume the: is at most one maturity level behind as the requirement.

For the specs which were published or are being worked on outside of W3C, we indeed need to have a reliable way to determine if they can be used as normative dependencies.

TBH preferably W3C could maintain a list of approved references using something like https://www.specref.org/ and any tooling using it would issue a warning if an unapproved spec is being used as a normative reference.

[csarven]

Example:

https://www.w3.org/TR/annotation-protocol/ normatively references two Candidate Recommendations:

[activitystreams-core]
Activity Streams 2.0. James Snell; Evan Prodromou. W3C. 15 December 2016. W3C Candidate Recommendation. URL: https://www.w3.org/TR/activitystreams-core/

[activitystreams-vocabulary]
Activity Vocabulary. James Snell; Evan Prodromou. W3C. 15 December 2016. W3C Candidate Recommendation. URL: https://www.w3.org/TR/activitystreams-vocabulary/

That's technically two Maturity Levels as per W3C Process 2015 given that Proposed Recommendation is between CR and REC. (In practise there aren't major technical changes between PR to REC but it is a separate level in any case. Naturally major changes would require the specification to go back to an prior maturity level.)

Moreover, https://www.w3.org/TR/annotation-protocol/#sotd states:

By publishing this Recommendation, W3C expects that the functionality specified in this Recommendation will not be affected by changes to the Activity Streams 2.0 [activitystreams-core] and Activity Vocabulary [activitystreams-vocabulary] as those specifications proceed to Recommendation.

Moreover, there was approval for REC despite the actual stability of the specification and having adequate implementation experience. It is possible to achieve some level of stability by referring to specific versions.

While there is some expectation of previous maturity level (with the exception of FPWD), and surely for good reasons, it is not strictly the case out there. There may be other examples, but I think once will suffice.

So my emphasis again is to seek feedback from horizontal reviews - including TAG, AB, Director, and possibly AC later on to formulate the specifics on dependencies in the charter so that there are no potential FO's down the road simply because a particular dependency is not at a certain maturity level. And again, there are other specifications by other standards communities that are categorically different than W3C's maturity levels.

[pchampin]

I think I remember @timbl talking about this not so long (during a Solid CG meeting??): as I remember, he was explaining that W3C RECs can depend on things that are one step behind in terms of maturity, precisely to make the co-evolution of standards more agile. I could not find anything about this in the current W3C process, though... But @csarven's example above shows there are precedents.

[elf-pavlik]

Based on today's follow-up discussion I propose that:

• We accept as CG submissions to WG the following drafts:
  • WebID Add WebID under Dependencies #40
  • Solid-OIDC
  • WAC
  • ACP
• We make Solid Notifications Protocol dependent on CG progress and are ok with the possibility of publishing the Solid Protocol without it
• We anticipate the need of dropping the N3 Patch and are ready to specify PATCH based on Sparql Update which is also already implemented

Keeping in mind that Solid 1.1 or 2.0 could add whatever didn't make it to 1.0

[csarven]

Keeping this as a general comment because what should be in 1.0 - including normative references, requirements, and everything else - shouldn't be resolved through this thread towards the charter. We had plenty of time to figure out the inner details of "1.0" elsewhere with a lot of pain and pleasure. :) All of the normative references are technically on equal grounds so I would not suggest splitting anything.

The charter is merely reflecting the latest consensus in the Solid Protocol (TR 0.10 and ED 0.11 that can be picked up for FPWD). If there are any anticipations or requests to change, they can first and foremost go through the current ED (or possibly another TR, 0.11) while it is a CG work item. The WG can make the call on its own work items, which includes adding deliverables (provided under scope) or removing deliverables/dependencies if indeed the WG reaches consensus to make such changes in the Solid Protocol.

[melvincarvalho]

• WAC

• ACP

Hi @elf-pavlik, I'm wondering if it could speed up the time to REC if only one of the two in version 1.0. They seem largely incompatible, potentially complicating the final spec.

This doesn't mean ignoring ACP or implementations. Given Solid's modularity, stemming from read-write web principles, different access control strategies can be adopted. It might simplify v1.0 of Solid to focus on one part, and include ACP in the spec later, either when time allows or after 1.0's completion.

This is just some food for thought, no strong opinion here.