Meeting minutes
Introduction and announcements
acoburn: anyone new, or who wants to introduce themselves? anything to announce?
Issue triage
acoburn: as usual, we don't want to spend more than 10 minutes on issue triage
w3c/lws-protocol#73
<gb> Issue 73 Scalability and implementation concerns regarding permission-based filtering (by wkerckho)
laurens: I think we can tag this one as ready for PR, it is included in one the PR recently opened
w3c/lws-protocol#77
<gb> Issue 77 Concerns about container creation (by pchampin) [ready-for-pr]
laurens: this one is also included in the proposed PR
pchampin: I started reviewing the container PR. Part of the suggestion in #77 was applied, but the body section still says MAY
<gb> Issue 77 Concerns about container creation (by pchampin) [ready-for-pr]
laurens: yes, still says MAY, but I agree we can leave that out from the proposal
… will remove wording and match expectations of this issue along with behavior of Solid and LDP
Issue 78 irrelevant MUST statement? (by pchampin)
acoburn: does this need discussion?
eBremer: I can do a PR
Issue 79 resource identifier needs clarification (by pchampin) [ready-for-pr]
pchampin: unless someone disagree, this one is quite straightforward
eBremer: I can do the PR for that one too
<Zakim> bendm, you wanted to ask why to actively prohib multiple containments
Container PR status and discussion
acoburn: I'll let laurens describe his proposal, captured in 3 PRs
laurens: I opened 3 PRs this morning, apologies for the delay
… I had a lot of comments from discussions with various people to integrate
… w3c/
<gb> Pull Request 81 Introducing support for Containers in the LWS protocol (by laurensdeb)
laurens: w3c/
<gb> Pull Request 82 Pagination for LWS Containers (by laurensdeb)
laurens: w3c/
<gb> Pull Request 83 Multiple Containment for LWS Containers (by laurensdeb)
laurens: note that these PRs are still marked as draft; I intend to remove the draft status from 81 after this meeting, and leave people to review it
w3c/lws-protocol#81
laurens: more details about 81
… some parts were spuriously removed, I will fix that after this meeting
… this PR describes the notion of root container, and focuses on single containment
… the wording might be too strict in some places, we might want to make it more lenient to allow multiple containment in *some* implementations
… note the extension of the terminology section
… it describes integrity of the containment, clarifies the deletion logic
… note that the parent container of a resource is no longer announced with rel="partof" , but wuth rel="up"
… not permission-based filtering on containers
… but a note describes how to do it
bendm: the phrasing is quite strict right now
laurens: correct; there was a lot of discussions about the original proposal being to flexible
… I'm hoping to merge it as is, but of course the PR is open for discussion
bendm: there is a MUST at some place, then a note says "MAY chose not to"
… are we describing the minimum requirements, or a maximum?
laurens: typically, for spec text we would describe the minimum requirements
… there are different ways of approaching this; I'm not particularly bound to the approach I took
… there is no systematic approach in the spec right now, on how to describe those options
<Zakim> acoburn, you wanted to ask about stictness and extensibility
acoburn: to echo what bendm was saying,
… we need to be careful about any restriction that we have.
… We want to support interoperability, which we get by being prescriptive.
… But we also want to allow future spefifications to build upon ours.
… Anything we forbid could be hindering that.
… If we restrict containment to be single-containment, we forbid multiple-containment in future extensions.
laurens: PR 81 supports only single containment. PR 83 softens it and adds the option to have multiple-containment.
acoburn: great; woudl be good to comment that in the PR.
pchampin: +1 on being prescriptive but also to echo Ben's concern
… what I see in section 7.5, there is a MUST and in the note a "MAY not respect the MUST"
… not saying this is wrong, but not a fan of adding requirements and then adding exceptions
… notes are non-normative, so they should not contain normative language
<TallTed> If that NOTE is retained, such MUSTs SHOULD be changed to SHOULD.
laurens: this is some more work needed on this section
laurens: moving on to the section on Container Representation
… some clarifications on the description of the format, but a lot of changes
… I would like the opinion of the group on the "mediaType" attribute of contained resources
… should we have a single value or an array?
acoburn: I don't have a strong opinion on this
… but bengo pointed out some time ago that we are describing a resource here, while mediaType is a property of a representation
laurens: I think we can modify that subsequently, once we have some implementation experience
… moving on to Operations
… introduce some wording (also in the IANA considerations) about content-negotiation of application/lws+json as application/ld+json or application/json
… application/lws+json SHOULD be considered equivalent to ld+json with profile; maybe we want a MUST there
pchampin: +1 about conneg: one should be able to get JSON or JSON-LD, not sure it should be part of IANA considerations
laurens: this is not in the IANA section, rather it is in the MediaType section
… minor editorial tweaks in the rest of the Operations section
… also the previously mention changed on rel=up replacing rel=partOf
… the section describing Creation of resources describes how to create an empty container
… in the example for creating a DataResource, I added Link relation types in the response
… also added an example of creating a container
… In the section about deleting resources, I added some working about deleting empty container resources and non-empty container resources.
… There are some proposals about requesting a recursive deletions, not sure they should make its way into the spec as is.
laurens: it would be good is everyone could review this PR and comment on it
<pchampin> s/subrobpic/subtopic/g
<Zakim> acoburn, you wanted to ask about recursive delete
acoburn: related to recursion; in my experience at Inrupt, there is a UX issue here.
… or maybe rather Developer Experience
… it is very handy to be able to do that
… we could reuse what exists in WebDAV
… I would prefer that, if possible, than reinventing something new
Pull Request 82 Pagination for LWS Containers (by laurensdeb)
laurens: this one introduces a pagination mechanism
… discussion is still needed about the notion of "large container" and threshold
… compared to the Google doc, the PR does not rely on JSON properties for navigating pages, but on Link headers instead
… this allows us to have the same container representation in both paginated and non-paginated cases
… the PR emphasises the opaqueness of pagination URLs
… I'll try to remove the draft status on this PR later this week
Pull Request 83 Multiple Containment for LWS Containers (by laurensdeb)
laurens: the wording in this PR may still be too strict
… I tried to contrast both approaches single containment vs. multiple containment
… the working prevents circular references
… this PR introduces text to move a resource to another container
… part of this text could make sense also for single containment (for moving large resources)
<TallTed> Multiple Containment should be similar to UNIX hard links. Single Containment with aliases/shortcuts should be like UNIX soft links. Single Containment without aliases/shortcuts will lead to undesirable data duplication in some deployments.
laurens: I think we should focus on the other PRs first
<Zakim> bendm, you wanted to ask about described server features
bendm: you are describing multiple containment as a features that servers may or may not support
… did we discuss the affordances that the server may have?
laurens: we don't really have anything in terms of classes/profiles of servers in the spec yet
… I think this is the first optional features that we would introduce
<Zakim> acoburn, you wanted to mention server description resources
laurens: if we introduce it, we should introduce conformance classes of sorts at the same time
acoburn: the storage description may contains "services" and "capabilities"
… services will describe endpoint providing the service
… capabilities could be extensions of LWS or could be optional features of LWS
… I think that multiple-containment could be advertised as a capability
<pchampin> +1 to that
acoburn: thanks laurens for walking us through these PRs
Input document acknowledgments, contributor status
acoburn: currently the lws-protocol document has a list of former editors, who are the editors of Solid specifications
… we have another input document (the Fedora specification) but we don't list its editors
… it is important to acknowledge the editors of Solid and Fedora
… but since LWS is not a refinement of Solid but more starting from scratch, it is a bit confusing to list them here
… this would be more appropriate in the introduction of the document for example
<TallTed> The Editors and Working Group would like to extend special thanks to Editors and Contributors of input documents, especially Solid ... and Fedora ... (and please, let us avoid previously used codenames in future!)
acoburn: We don't need to make a decision right now, please think about that.
… We want to be respectful, but also accurate.
<acoburn> https://
acoburn: At the end of the document, it is common to have a list of contributors
… We have flexibility on what we define to be an "editor", an "author", a "contributor"
<bendm> +1 to move the previous Solid editors to a less-LWS-specific location
acoburn: The link above is how a previous WG defined these notions.