Skip to content

Latest commit

 

History

History
131 lines (101 loc) · 12.3 KB

2023-04-19.md

File metadata and controls

131 lines (101 loc) · 12.3 KB
Raw

W3C Solid Community Group: Weekly

Present

Announcements

Meeting Guidelines

  • W3C Solid Community Group Calendar.
  • W3C Solid Community Group Meeting Guidelines.
  • No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
  • Join queue to talk.
  • Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed.

Participation and Code of Conduct

Scribes

  • Laurens Debackere

Introductions

  • name: text

Topics

Overview of today's agenda

  • SC: Today's meeting will focus on the Solid WG Charter that follows 2023-03-22 meeting topic for reviews: https://github.com/solid/specification/blob/main/meetings/2023-03-22.md#solid-wg. See meeting minutes since 2023-03-29 correcting and improving the charter.
  • SC: In previous meetings, we've agreed that we will prepare issues/PRs until we have agreement within the CG; upon agreement, PAC will be assigned to merge them.
  • SC: Questions or suggestions for today's agenda?
  • SC: First open PRs then issues:

fixed spelling and such

URL: solid/solid-wg-charter#27

  • SC: Group agreed that this PR can be merged. Pending PAC's merge.
  • SC: PRs will be brought to a point where there is consensus in the community. Pierre-Antoine will then bring this forward.
  • SC: Some minor remarks on the date format (not necessarily important).
  • PA: In favor of ISO format for dates.
  • SC: Are there any objections to change the date format? If not, SC asks Ted to update the PR to update the document to the ISO format.

Clarify normative, tentative, new Deliverables

URL: solid/solid-wg-charter#28

  • SC: The PR was updated to mention the role or involvement of Solid CG with respect to getting the deliverables into the WG. Still an open question whether, for example, all the normative references of the Solid Protocol should be Working Draft for the Solid Protocol to transition to Candidate Recommendation. We don't have sufficient guidelines, for example, in the context of non-W3C specs such as IETF specifications (RFCs), on what status the normative references should be. Perhaps Pierre-Antoine can clarify on this.
  • PA: Is the problem with existing normative refs in current specification? This would be an item for the WG to address.
  • SC: The references the specification depends on — e.g. WebID specification, N3, WAC, ACP, Solid OIDC — are under consideration to be incubated by Working Group (mentioned by SC in recent discussion).
  • JZ: We're listing specifications in Solid CG and other CGs; is there some difference in status in specifications?
  • SC: They all have roughly the same maturity, can all be considered draft specifications without official W3C recommendation?
  • SC: Solid protocol just happens to refer to this work.
  • TT: The normatively referenced specifications should be no more than one step behind the specification under consideration.
  • SC: I've checked some documents about the transition and the process but couldn't see it clearly. Might be an unwritten rule. That's how I remember it as well but would be useful to have a pointer to this requirement or guideline.
  • PA: +1 to what Ted says. I am trying to find a normative reference for this rule. If the Solid protocol needs a normative reference, they need to be mature enough to be recommended by the Working Group. That is up to the WG to define. For other CG's it is more complicated.
  • SC: Currently the PR is worded such that these are tentative deliverables, which have to be considered by the WG.
  • EP: We have to be coherent in expectations on ourselves. If we follow this rule, that normative references can be at most one step behind, if no other WG or proposed WG is addressing this, then the Solid WG will have to address this itself. We need to decide what we think are "hard dependencies" for the Solid protocol, i.e., what references are required for a conformant implementation?
  • SC: Agree with EP, the Solid Protocol will need to reference certain specifications. Guidelines on the status thereof needs to come from W3C, and the WG will have to conform to that. We shouldn't make this decision here. For example: If the WG decides Solid-OIDC or N3 is not desirable as a reference, then they can seek to fill this gap with other specifications.
  • PA: +1 to the consistency argument. We must be consistent in the process. We have to mention these CG specifications that are currently normative references. What we should not commit to in the charter is whether those references have to become specifications of their own. The idea is that the separation in documents might not match the current separation of the CG specifications. The charter should give a high-level view of what the WG is expected to address. We should not be too specific in how these references are to be used in the final result.
  • SC: Would you say that those specifications that are listed in the purview of the Solid CG should be listed as a tentative deliverable in the charter, as they currently are in the PR?
  • EP: There might be a benefit in not being over-specific in how we are to deliver the scope. For example it might be beneficial to extract the storage definition, similar to WAC, ACP, etc., where the protocol groups these different specifications. Maybe we just don't have to commit at the start on the how, and focus on the scoping right now.
  • EP: Question to PA: Looking at the deliverables section in the charter, how specific should we be?
  • EP: Currently the deliverables section matches the organization of the specifications in the CG. Isn't this over-specific for the charter?
  • PA: I think it is good to point to existing work that is in scope, which is the goal of these pointers in the charter. There is a strong dependency between the specification and these references. I don't have a strong opinion on whether this should be in the scope or deliverables section.
  • SC: Just a reminder that they were introduced based on prior observations on other charters and formal objections (e.g., Devices and Sensors WG, Web Application WG). See past discussion. The general idea is that if it is not sufficiently incubated, it should be listed as an in-progress or tentative specification that the WG could consider as a deliverable.
  • EP: We could have a list of more adopted drafts, e.g., WAC, ACP, etc. We cannot expect the final protocol to have the functionality, if it is not in the scope of the WG.
  • SC: Suggestion that PA review the PR and validate whether this is along the lines of the W3C guidelines and is sufficient to wrap up the deliverable.
  • PA: Yes, I will review this PR and try to get feedback from other W3C people about how to address this. I like the idea to list them as other "adopted" drafts; however, this might indicate a stronger commitment.
  • EP: Since you mentioned N3, personally I think the protocol would be in a good state even if we don't depend on this as we have other approaches for this. We should also clarify dependency on WebID, as this is a relatively old draft and perhaps consider adopting it in the WG as a normative dependency.
  • SC: As these six specifications (Solid-OIDC, WAC, ACP, Notifications, WebID, N3) are of a similar status, we should leave the flexibility to adopt them if the WG deems these relevant but we haven't made a commitment. All we have committed to is that they are a tentative deliverable and we may adopt them.
  • TT: I have found a relevant thread from a TAG discussion (2012), which mentions there is no strict rule but there is guidance in transition process which effectively requires that the reference should have a status that is no further than one step behind the specification. Otherwise the reference should be informative instead of normative.
  • EP: If something in an informative reference is omitted by an implementation, then an implementation ignoring it would still be conformant?
  • SC: Yes
  • TT: You just say "x MUST y", and it becomes a normative statement. It might need to be in a normative section.
  • SC: We should wrap-up. Encourages everyone to review this PR.

Scope needs to be tightly defined with narrow focus

URL: solid/solid-wg-charter#9

Clarification on Solid and comparisons

URL: solid/solid-wg-charter#5

  • SC: Editorial feedback is requested, can happen at any time.

Update mission

URL: solid/solid-wg-charter#7

Review from TAG should be requested prior to Member review

URL: solid/solid-wg-charter#15

  • SC: Will all horizontal groups be reviewing or do we have to request review of specific group?
  • PA: Expectation is that we request review from all horizontal groups.
  • SC: So the community group should request TAG's review?
  • PA: Yes

JSON-LD Context URI

  • SC: Noting that published Solid-OIDC JSON-LD context is https://www.w3.org/ns/solid-oidc-context.jsonld
  • SC: Proposed (not yet published) Solid Notifications Protocol JSON-LD context is: https://www.w3.org/ns/solid/notification/v1.
  • SC: Should we set a URI template for all JSON-LD context URIs or leave it open to specifications to use a template of their choice?
  • SC: notification/v1 is similar to vc/v1 and credentials/v2.
  • SC: If you have any suggestions on this approach or propose changes, we can pick this up in the Matrix chat? Are there any reservations or recommendations for this context URI?
  • EP: Aaron Coburn has mentioned in the past that implementations should avoid fetching remote contexts and store this locally. If nothing is available at the URI it is considered.
  • LD: I had similar conversation with Aaron, somewhere in VC community there were security considerations about fetching remote context, it appears that the best practice is to use local copy of the context
  • SC: I more specifically want to ask how the URI structure of JSON-LD contexts should be standardized for contexts within the Solid specifications. If it is dereferenced, the relevant context should be returned. But more specifically, we have to determine what the URI looks like. The published version of the notifications protocol already mentions this URI and asks for this context to be published. Once the specifications are merged and thus we are expected to publish these vocabularies, then these URIs should be made available and resolvable.