Meeting minutes
Notifications
laurens: we wanted to start with test suite, but given presence we will start with notifications
… i find the activity on the PR relatively low, i want to understand we we don't have much interaction
… are there any concerns we need to address, or everyone feels happy with the state of PR
<Zakim> termontwouter, you wanted to ask reasons for making notifications part of the core spec
laurens: which parts we want to elaborate on
termontwouter: why notifications are so imortant to be in this versiuon?
laurens: we have them mentioned in the charter
… other specs like access requests and grants rely on notifications
… it would be strange for those to define their own notifications system
… there is incubate body of work on notifications in Solid, we should address that
… we could just have vote on that, but let's discuss it first
<Zakim> acoburn, you wanted to talk about prioritized requirements https://
acoburn: we did prioritized list of requirements, notifications were nr 7
… it was fairly high
elf-pavlik: I added a comment on SSE.
… I also implemented webhooks.
… Those are the two I've implemented
… SSE are a bit problematic.
… You can't take advantage of the regular authn/authz flow in SSE.
… Rahul has an interested approach with the QUERY method.
… Which could be very efficient.
… Instead of SSE we could consider just streaming HTTP.
acoburn: i would be a big fan for minimal scope for the PR, there are 3 channel types, two sync and one async
… one option would be to define one sync and one async
laurens: i would say one client server, websockets, sse, streamin http
… and one server server where webhooks make sense
acoburn: i'm more familiar with webhooks and server sent events
laurens: i like websockets and server sent events that api surface is pretty limited
… we may need to define more auth flow and protocl
elf-pavlik: we can use the same auth workflow as with GET
acoburn: let's say once you subscribe to container and anything contained, the way that model is defined can i get all events,
laurens: i would propose to have couple of votes, i want to know if we keep requirements to resource changes as deliverable
… we can split pr in two parts, for server to server is see very few alternatives
… we can have separate vote for server to server webhooks
and revise client to server and have separate vote
<Zakim> termontwouter, you wanted to clarify concerns
elf-pavlik: there is prior work on LDN in Solid CG, I use webhooks for simplicity
termontwouter: ... up til now notifications were about changes on the resource server, yesterday we decided that we want to auth systems out of it
… why should we enforce those authn mechanisms to use the same notification system as resource updates
acoburn: the way i was thinking about, it, server uses some notification mechanism but server could choose what it uses
… as long as user supplies the inbox the server sends something to the inbox
termontwouter: if we say we can plug in any system using profile and www-authenticate header
… why would we couple it with notifications via some inbox?
… server doing oauth and providing custom api, would still need to implement lws specific part
laurens: i need to change access request and grants spec to also profile notifications system, it only uses the inbox part
termontwouter: that would be a good approach
acoburn: some auth parts of the notifications spec may need some revision
… we can't guarantee delivery, someone could provide wrong inbox
… that inbox may not require authentication, it may support particilar kinds of authn
… it may support authn methods that the originating server does support
… the most we can say is to look at www-authenticate header and negotiate what is supported by both
termontwouter: makes sense
acoburn: i wrote about webhook authn being overly specified, if we use http signatures we just need to follow accept-signature response
… we probably just want to rely on www-authenticate in the end to negotiate
laurens: for me it's fine to just mention the negotiation aspect, should we at least specify something about public key material for the server
laurens: for now is up to implementation
acoburn: we should also just use self-signed identity authn suite
pchampin: first one is reaction to pavlik, i may be missing something query method is defined as safe and idempotent, i'm not sure if really matters for subscribing to the stream of events, we may need to rely on POST
… reaction to aaron, service description is not CID, i know that I argued against using CIDs, we should consider defining service descripition as extension of CID
<Zakim> jeremycaine, you wanted to ask about guaranteed notification
jeremycaine: we can't guarentee delivery of notifications, server will log everything, we can get endpoint on the other end
acoburn: it depends on how we define it, we can use outboxes from ActivityPub, you can think of it as container
… instead of posting a message you can just ping and ask that something fetches it
… authentication is just lws authentication
laurens: push based vs pull based is interesting, most solid was push based, limited material within solid in pull based
jeremycaine: open telementry is getting a lot of presentce
… do we need to decide how to implement notifications?
acoburn: we need to define protocol, implementation is out of scope, if we define minimum set of options eg. webhook and streaming fetch, there can be others build on top of that
elf-pavlik: about finding keys, in Solid Notification the response to subscription can include "sender"
… that's how you would discover the key
laurens: i don't hear much objection to the idea of splitting PR #129 and first addressing server to server
<gb> Pull Request 129 feat(notifications): Introduce the LWS notifications specification as an optional service (by laurensdeb)
laurens: later introducing client to server PR
… i hear discussion on push vs pull based, i would be hasitant on introducing a pull based model at this time
… i don't think it is high priority
laurens: i would want to bind channel to something that is defined
termontwouter: defining general extension point
laurens: i think it is already possible, uri in response could be a pull based source
elf-pavlik: with light vs fat ping webmention is an example of light one
acoburn: we described 3 defined mechanisms, we want to tweak the text that it is not a closed set
… i would strike capability urls, if we don't use SSE and websockets even more
… in discovery we have in PR subscription type and conformsTo, can we align those?
… envelope we may remove phase
… activity can be obj or array, we can require array to make parsing easier
… for access request we use target for subscription topic
acoburn: AS target has a meaning, in subscriptions we used topic, terminology between ODRL and AS doesn't align
laurens: target is used in similar way as an audience in AS, i'm open to suggestions
elf-pavlik: we picked topic from WebSub
<laurens> PROPOSAL: To keep subscribing to resource changes (notifications) in scope as a deliverable for the LWS WG.
<pchampin> +1
<termontwouter> +1
<laurens> +1
<jeremycaine> +1
<acoburn> +1
<gibsonf1> +1
<eBremer> +1
RESOLUTION: To keep subscribing to resource changes (notifications) in scope as a deliverable for the LWS WG.
<laurens> PROPOSAL: To split the PR #129, first defining a server-to-server notifications protocol and subsequently introducing a server-to-client notifications protocol as a separate PR.
<gb> Pull Request 129 feat(notifications): Introduce the LWS notifications specification as an optional service (by laurensdeb)
<laurens> +1
<gibsonf1> +1
<pchampin> +1
<termontwouter> +1
<eBremer> +1
<acoburn> +1
<jeremycaine> +1
RESOLUTION: To split the PR #129, first defining a server-to-server notifications protocol and subsequently introducing a server-to-client notifications protocol as a separate PR.
laurens: with that we can wrap up
ACTION: eP to provide details on streaming http
<gb> Cannot create action. Validation failed. Maybe elf-pavlik is not a valid user for w3c/lws-protocol?
acoburn: i'm more comfortable with idea of resources that can be both container and data resource
gb: excelent, i wish i could be there with you
Terminology
acoburn: last evening we discussed some of the definitions
… if we define things as capabilities, we can treat resources as mixins rather that fixed identities that can't be anything else
… if we describe container as resource that is capable of containing things, it doesn't prohibit if of having other capabilities
… if container has one capability and resource other capabilities, as long as they don't conflict it could have both
… we can have a well defined way of doing it
elf-pavlik: in hypermidia there's also term affordances commonly used
Test Suite
laurens: i noticed that you opened a PR with some scaffolding
ericP: I created a PR with a generated scaffolding of a strawman test suite (with underlying JSON-LD) following N3 and SPARQL ones
… I tried to capture all behaviors we'd need in these tests, and defined them into traits ('what we are testing')
<acoburn> Test suite strawman
ericP: The HTML has a source link to the place in the spec, mailing list, minutes etc. where the test came from.
… Each trait has a request and expected response.
… In the code, there is a directory with test resource, one with dummy certificates etc. to manage the needed surrounding data.
<Zakim> elf-pavlik, you wanted to ask about similarities and differences to Solid conformance-test-harness
elf-pavlik: Can you compare with the one of Solid?
… Is this just data or also some tests?
discussion on test data vs tests
ericP: There are also tests, based on this scaffolding.
laurens: We'll need an implementation report listing the cases we want to cover.
… And then have a harness executing those.
samu: I have no schedule, but here to listen. I can definitely build on this test data, in the context of an NLNet project.
pchampin: Just clarifying W3C requirements.
… The Process requires a number of implementations, and a report documenting those.
… It does not require a test suite, or define it, but it is a very common approach.
… The RDF community has defined a vocabulary to describe tests and manifests, which was used for a number of related specs.
… Those specs did merely define the manifest (test data), but no harness, leaving that up to implementers.
… Eric might know more about how the SPARQL WG did this.
ericP: SPARQL and LDP both included protocol validation of servers, but I'm unsure if this was driven by a manifest.
pchampin: There is a manifest for SPARQL protocol, but it looks quite different from the other manifests.
… It is okay to have some tests be manual; full automation is nice to have but not a requirement of the W3C.
samu: I'm familiar with this in SHACL, which has a manifest but not a specific harness.
… My plan is to produce an implementation of the protocol as well as an implementation of the tests.
… I agree that a harness is not a necessary requirement, but since there is a widely used one we might as well adapt it.
laurens: We mentioned client testing. Do we consider that out of scope, given the lack of strong requirements on that side?
… I would like us to converge on the agreed upon test cases we have, and ideally also some reusable test harness.
samu: Absolutely
<Zakim> elf-pavlik, you wanted to clarify if conformance-test-harness will be used and how it depends on data from specs
samu: I could also build a server that act as a test for clients, but best not drive clients using test-specific requirements.
elf-pavlik: Is the plan to reuse the existing work on the test suite?
samu: I'll aim to reuse as much as possible, given the effort that went into it.
… I would not impose all requirements of the current harness on you.
acoburn: The current harness relies a lot on RDFa, which I would avoid (re)using.
elf-pavlik: Seva, from the User Graph Journey CG, passes RDFa through a script into JSON-LD.
samu: Does not matter how I get the data, I will indeed transform it before working with it.
acoburn: RDFa is so niche, and unsupported, I'd rather not rely on it.
samu: I'd further argue against requiring an implementation of the tests, which is software and has a different life cycle than the spec.
… If we do it, think about the continuity of the software.
acoburn: Case in point, the LDP test suite, which is no longer maintained.
… When I was working on LDP, after the WG was over, this was no longer touched. I tried to keep a fork of it up to date, but this is an important difficulty.
samu: As a counterpoint, I implemented the test suite of SHACL and still report a bug to the WG because it was still going on.
elf-pavlik: It would still be useable a few years later.
samu: As a decision maker in production I would not touch something that old.
elf-pavlik: I'm just arguing that it would make it easier if there is some easy-to-set-up implementation.
samu: I agree, but it should not be a product of the WG.
acoburn: This is where the work Eric was showing comes into play. There is not only code, but also a lot of data.
… As a WG we can publish this data, that is based on the UCs. Each implementation can then build on top of that.
samu: I can then take the actual requirements and materialise it into manifests.
… What is your timeline?
laurens: For a CR, this fall, so we hope to get most issues out of the way by then.
… While we might already work on a test suite in the meantime, but after that timeframe we'd have a relatively stable spec.
… A stable test suite by the end of the year would be ideal.
samu: and a stable implementation as well?
pchampin: We first need to the test suite, that is a priority.
samu: I understand, but to build it I would have to go back and forth with the spec and an implementation.
jeremycaine: Should be put that into the timeline?
<Zakim> ericP, you wanted to say that the harness becomes worth it when two folks implement their own server tests. that said, we can help them collaborate and not take it as a WG requirement
ericP: The implementation if not really our problem, but a question of willingness in the community to maintain it.
… As a community project, it also does not have to be perfect / over-engineered.
… So there is no reason for it to be the W3C, but there might be a bit more continuity that way.
… Is it possible to start elaborate the current Test Suite and add committers / managers to the project ?
pchampin: Yes, we can do that, but we might have a separate repo instead.
… About the calendar, after CR we start to request test reports, so the suite needs to be present more or less by then.
… When we believe the spec is stable enough, there is a lot of hoops to get it published, so then we have time to finalize the suite.
… Regarding the maintenance, this is indeed not the job of the WG.
… The data part (manifest) could either be maintained by a 'maintenance WG', or by the CG.
… It would be good to have a clear link between normative statements and tests. ReSpec has some tooling for that. It is not really RDFa, but a custom annotation.
… It adds some classes to normative keywords, and an attribute pointing to a test URL, for example in the manifest.
… It would be much easier to spot any discrepancy between the spec and the test suite.
<Zakim> elf-pavlik, you wanted to mention opportunity of having NLgrant already approved
<pchampin> https://
elf-pavlik: It's good that ODI can finance this work with an NLNet project.
… About the Process hoops, I feel it is not a good idea to get most implementation feedback only after reaching CR.
laurens: Let's wrap up the test suite discussion.
… Who is going to lead this on the side of the WG and on the side of the implementation feedback?
… Samu, of course, and I would hope Eric as well. How do we follow up on this?
… What parts of the spec do we focus on the first?
samu: How do you refer to auxiliary specs?
laurens: There's profiles, and mandatory parts that are separated from the core spec.
samu: This has a bearing on the modularity of the test suite (one vs one per subspec)
ecirP: The traits should address this partially already.
… s/ecirP/ericP
acoburn: Right now, this is editorially split up into the core spec and some subspecs, but this does not differ much from one spec with mandatory and optional sections.
… That said, I'd expect that a test suite picks one authentication method (not SAML)
samu: I'd have to test all authentication suits.
acoburn: You don't need to test the SAML setup itself, just use test data in that format to check if it works.
samu: I would of course start from the core spec.
laurens: Agreed
… Is there a recurring structure for feedback that works best?
samu: Anything would work. Let's say monthly to start.
laurens: I'll keep track of that as monthly agenda topic, and reach out one or two weeks in advance each time.
elf-pavlik: Would it be possible to prioritize some experimental options still under discussion?
samu: Absolutely, but I'll first need some time to set things up. No need to wait for stability instead of valuable feedback.
… It would be nice to first settle on an initial feature set to start with?
acoburn: Yes, let's start with SSI-CID authentication.
… In the core specification, we have three different roles. The test suit acts as a relying party, and tests some features of a resource server, and some features of the authorization server. Those two servers are two important components
… If you have those, we can test features like the discovery mechanisms, the container representations and operations, and the data resource representations and operations.
samu: Can we first do this without authentication and authorization? Just the data model and the operations?
acoburn: We can. We rely on the WWW-Authenticate header, so we can initially focus on public resources.
samu: Happy to aim for that
… I think I will start with the server implementation, and not the test suite.
<Zakim> ericP, you wanted to mention that folks often clarify proposals and arguments in the form of tests. having those in the test suite (marked appropriately) is useful
acoburn: Sure, but recognize that the spec is still in flux.
ericP: People often use tests to clarify proposals or arguments. In SPARQL WG it worked well to put both in the test suite.
… I am tempted to let it come naturally what to implement first and what next.
Terminology
acoburn: yesteday we finished the description of Storage Root. We are at the point of Container.
… Container, Data Resource and Metadata Resource are probably the most contentious we have left.
… Conversations happened yestedray in the meeting and after the meeting.
… One outcome was to describe the resources in terms of "traits", each trait being defined in a given section.
… I have slimmed down the def of Container to 3 things: managed by the storage, able to enumerate a collection of resources, and conforming to "Sec 8 Containers"
termontwouter: this is generally good, but there is a potential clash with other operations
… it feels that the container is the thing that enumerates; perhaps formulate it has "having a container description"
acoburn: there may be representation of that resource that contain no enumeration at all; as long as it is *able* to enumerate, it is ok
… there is a long history in Solid and Fedora where if you GET the container, then all the items are there
… no provision for paging or other things
termontwouter: should we have a container description the same way we have a storage description? as a form of metadata that contains the enumeration
acoburn: I think that's the purpose of the data model that we are currently providing
… Also, in our spec today, a container supports certain operations (POST to create)
<Zakim> termontwouter, you wanted to talk about clashing operations
<Zakim> elf-pavlik, you wanted to bring up moving resources between containers
acoburn: I would word it as a container needs to support the container representation, and support the POST operation
elf-pavlik: about "managed by a Storage"; we mentioned that it would be nice to be able to move resources from one container to another, by patching the linkset
[discussion about the wording of "managed by a Linked Web Storage"]
pchampin: is Container not a subclass of LWS Resource? Should this appear in the definition? The "whose lifecycle is managed by a Storage" should probably be moved up in the LWS Resource definition.
laurens: I think the definition should constrain the contained resource's lifecyle to be managed by the same storage as the container
ryey: what exactly is managed by the Linked Web Storage? In the past I proposed things like "views", which would not be "managed by the Storage". Is this definition allowing for this?
termontwouter: I think it should be allowed, and should be seen as a resource that *is* managed by the LWS server.
… the binding between a URI in the storage namespace and what it binds to is managed by the server, even if the backend is somewhere else.
ryey: I'm not sure; suppose the software generating a set of resource for LLM usage, which is dynamic. Are those resources really managed by the storage?
acoburn: what I was trying to get at is: assume you have a container storage.example/data/ containing a number of items.
… data/1, data/2, data/3 ; then there is storage.example/foo/ with a completely different kind of relationship
… you can have it, but lws:contains would not allow that particular kind of thing
laurens: what is important for clients is that lws:contains has some dependable semantics for it
… if some implementation introduces additional semantics, this will be harder for client
ryey: my original question still holds: do we want to support such extensions?
termontwouter: this could be solved by the capability approach; you could declare additional hierarchy types you support, which would be distinct from lws:contains
ryey: that makes sense; so that allows other kinds of resources to exist?
acoburn: correct; we define several categories, not excluding others
ryey: then the "managed by the storage" should not be moved up to "LWS Resource". Some resources of other categories would not be managed by the storage.
termontwouter: I think that's a different interpretation of "manage"
acoburn: I agree; there is a lot of thing that happens underneeth that's out of scope of LWS.
ryey: ok
<Zakim> jeremycaine, you wanted to ask about union intersection of containers
jeremycaine: let's say there is a data resource, that has a URI that maps to an external system, e.g. banking transaction history
… the Storage may not be allowed to delete this resource
… when we create a resource, should we be able to tell the storage what it can or cannot do?
acoburn: I don't know that we want to define that. This could be implementation specific?
laurens: should this be managed at the authz layer rather than HTTP?
… There is nothing preventing you to create a mechanism allowing the creation of read-only resource.
… I would be careful not to mix HTTP operations with authz concerns.
elf-pavlik: what you can do in Solid, you can create a resource via PUT, then modify the ACL to prevent deletion.
… I agree that it is related to authz.
acoburn: [shows a part of the Fedora spec: "§3.9 External Binary Content"]
… the Fedora server is not managing the data in the remote server, but it is managing the resource that is providing access to the external data
jeremycaine: I'm assuming that LWS will be linking to external data, adding authn/authz layer
acoburn: there are many ways to implement it
laurens: I see LWS as a protocol layer that you can put on an existing API
… what I dislike in Fedora is that they make this external link very explicit. This should not be a concern of the client.
jeremycaine: so in the test suite, a valid response to DELETE would be "not allowed"
<Zakim> termontwouter, you wanted to react to rui & laurens
acoburn: yes, a server can always refuse what the client is asking
termontwouter: I think we should rephrase it in a way so that it is clear without requiring the whole discussion that we just had
… I was a fan of the "namespace" / "workspace" ideas :)
acoburn: I used the word "managed" because I saw it in other specifications
… but I'm opened to use another one
… The Terminology should be high level. The sections with the normative text can be more precise.
<eBremer> pchampin: +1 on keeping terminology high level, managed may be confusing but the whole text needs to work
<eBremer> ... we focus on lifecycle management, not the content, some resources are proxies managed outside, from the point of the client it is managed by the storage
<eBremer> ... i was concerned about how acoburn described containers earlier,? does it imply read only containers?
<eBremer> acoburn: we need to clarify it in text
<eBremer> ... interesting things has been said on interesting containment hierarchies, it should be considered data resources
<eBremer> ... because something has a hierarchical structures we don't need to schoehorn it as a container
<eBremer> ... does it mean that some resources would be neither container or data resource? i'm open to discussion but we need to clarify things
elf-pavlik: the client does not know how LWS resources are stored, only how they are published
… isn't "lifecycle" too focused on implementation?
acoburn: I like "lifecycle" because it relates to the HTTP operations than can be performed
elf-pavlik: how about "it supports the corresponding operations"?
<ryey> +1 to elf-pavlik regarding both the problem words, and the suggested alternative
acoburn: I'm trying to balance between a high level definition, and something not too abstract like "it is a thing, see section X"
<Zakim> elf-pavlik, you wanted to propose published instead of managed
acoburn: the current definition is very small ("LWS Resource that conforms with Section X")
termontwouter: so do we need it? does it have any property that a container does not have?
[discussion about whether "content provided by client", vs. read-only data resources]
ryey: back to containers: does the wording about "enumerate" have anything to do with performance requirements?
acoburn: it does not imply anything about performance or paging
… it is up to implementation to decide how enumeration happens; we describe it in more details in the corresponding section
ryey: regarding data resources: a container can also be a data resource, as well as metadata resource
gibsonf1: yes!
laurens: as I look at LWS, a container is strictly something we have to introduce to because we need a root from which other resources can be discovered
… people try to assign additional meanings to containers, and this should be allowed
… but there is also great use in the distinction between having a container that is partly server / partly client managed, and a data resource
<Zakim> elf-pavlik, you wanted to comment that capabilities/ affordances / mixins allow more specific types to be defined
elf-pavlik: if we think of these in terms of traits / affordances, container is clear
… then what would be the special affordances of data resources? if they add nothing specific to LWS resource, then so be it.
acoburn: if we find that the concept of Data Resource is the same of LWS Resource, then we should remove one of them
laurens: the PUT should be the distinctive feature of Data Resource
<Zakim> jeremycaine, you wanted to ask containers are not data resource even if a container only contains one data resource
pchampin: I take back my argument about the "read-only data resource", this would be just a LWS Resource
jeremycaine: I think we should specifically say that a container is not a data resource; a container could have an associated data resource
… that keeps things simple
acoburn: we don't actually have consensus on that point
… if we define those categories as sets of capabilities, an implementation could delinerate them as exclusive categories
… another implementation may allow for resources that have the properties of 2 categories
… if we could agree on that, it could provide for gibsonf1's use-cases and others'
gibsonf1: I agree with the idea of merging LWS Resource and Data Resource
… we have a notion of "intelligent PDF"; you can get it as application/pdf, or as a container that contains pieces of that file, extracted into data
… the key issue is semantics, which is what Linked Data is about.
… If we have LWS not supporting semantics, then what is it?
termontwouter: I would agree
… laurens, you want containment to be void of any other semantics
laurens: I think the application/lws+json representation of the container should be void of any other semantics
termontwouter: I think we all agree of that
… Data Resource is "any LWS resource that is not a container"
<ryey> It doesn't mean Data Resources is not Container Resource. The definition did not say "either this or that".
laurens: we should be thinking a the readers of the spec
… defining something negatively is confusing
… PUT is defined for Data Resource, and not for Containers
termontwouter: if PUT is the defining feature of a Data Resource, that's what the definition should say
<eBremer> pchampin: fred, your inteligent pdf use case, can you put to pdf content?
<eBremer> gibsonf1: if i do a PUT of data to it, if i upload a file to it, it does that, if i add items to the container they get added
<eBremer> pchampin: i would keep the distinction, do we need to say it supports GET? I would say it supports PUT
<eBremer> ... we must provision for containers to contain something that is not data resource or container, it can be managed by external service
<eBremer> ... those would be just LWS resource with no additional behavior specified
<eBremer> ... data resources you can PUT, containers give you something very specific
<eBremer> ... DELETE is i guest on linked storage resource
<eBremer> pchampin: with the trait approach data resources and containers are not specified as exclusive
<eBremer> ... what PUT to a container mean? implementations can define it
<eBremer> .... if you try to PUT container description to modify it
<eBremer> pchampin: i like the idea of traits / mixins
<eBremer> ... read only would be just LWS Resource
<ryey> +1 to pchampin regarding the separation of these definitions; also, Type Index is probably read-only
acoburn: I suggest to add in LWS that it supports GET; to add something to Container about how to add items
pchampin: suggest to word it as "any ability to add items is done like this" / "any ability to modify the content is done like this"
ericP: whether or not you can store arbitrary data is a container is an important part of Solid. If the response is "it depends" there is a problem.
… gibsonf1 has an implementation that meets his needs. acoburn had issues when dealing with etags.
… we do people a disservice by not telling them precisely how to implement this.
… I would suggest that gibsonf1 and acoburn try to find a common ground, and we put that in the spec.
acoburn: problem with conditional request is if you try to modify the enumeration with a PUT
<Zakim> ericP, you wanted to say that devs and users are going to want to know whether they can store data in containers. it fundamentally affects the architecture of anything stacked on top of LWS. if we dance around this, we'll apepar to make progress but we won't enable Frank's clients to run on Aarons's server and visa versa.
acoburn: if the PUT on containers is meant to change other data than the enumeration, then I can see a way forward
jeremycaine: if we were to say that a container is not a data resource, then that goes against what gibsonf1 is talking about
… what if we say "a container is not a data resource, but a data resource can contain other resources"?
… you could PUT a markdown file, then access Section 4 of that file as a "contained resource"
<Zakim> jeremycaine, you wanted to ask I think Fred example is really a feature e.g. get chunks of data of the applicaton/pdf (I suggest an intelligent pd f is a Data Resource)
gibsonf1: on the ETag issue: the way we do it, every resource has a last-change state.
… If you change any resource, it changesthe etags all the way up the container hierarchy
acoburn: that addresses one part of the issue, but we can leave that for earlier
<elf-pavlik> to bad ericP
<Zakim> elf-pavlik, you wanted to check how etags tie to media type
elf-pavlik: I support ericP's proposal to list the known issues
laurens: I like the way that resource operations are specified in the text right now
… I encourage people to look at it
… I don't want them to preclude how people implement them, I would support removing text that precludes that
… I would strongly oppose any requirement for servers to consider all containers also as data resources
termontwouter: I agree
laurens: lets start with easy resolutions
acoburn: I ammended the text for data resource
acoburn: for data resources I added the line "any ability to update or delete an existing data resource follows...
laurens: a reason to split up the operations over containers....section 9 is just operations
elf-pavelik: not forbidden to move resources between containers
laurens: would want input from the WG to propose it as a separate PR
acorburn: back to def...the main quality is about describing the cpaabliity of the items
… if you think of a class hierarchy...
… an instance of a LWS resource may be a data and container
termontwouter: of what a lws server allows is fully up to a particular server
acoburn: i do think we will need to flesh that out.
… i think there are answer to those questions in a fairly simple manner
acoburn: any objections here?
acoburn: metadata resource...entirely absent at the moment...lots of prior art
… solid brought that in as an auxiliary resource
… one: the rep of that resource is text/turtle
<TallTed> "whose lifecycle is bound to the" **LWS**, not Storage "resource it describes"
acoburn: base level requirement. 2nd the life cycle of that is bound to that resource
… applies to resources that are not self-describing
… less useful for self-describing resources like turtle
<Zakim> gibsonf, you wanted to ask about metadata
gibsonf1: you agree, to satisfy req, someone has to make another resource for this
… there are implementations that dont have to do this
… in general, everyone is going to be data first
… having to make another resource doesnt make sense
<Zakim> pchampin, you wanted to respond to gibsonf1 about "resource"
gibsonf1: if your implementations has limitations, then fine make another resource
pchampin: we should be talking about interface not representation. the URI provides this
… that is all I am reading when I read the spec
… you seem to believe we are constraining things when we are not
… its an interface problem. I do not think the spec is not against a data first arch
tallted: metadata resource - should be LWS resource at the end
termontwouter: if you would request a metadata representation from the resource itself
… that response would include content location to the metadata location
acoburn: additional context - in all of those cases, you have a resource, a link header with a rel=describedby. thats it
… that is where you would go to get the representation of that resource
laurens: as I understand, this is something that is referenced from the linkset
… nothing in spec about the metadata resource
… linkset is something that contains all of the linkheaders
acoburn: three options. prior art. LDP, Fedora (inherits LDP) and solid which has its own. what they do for these description resources, the server auto creates this description resource
… the client does nothing
… likewise there can be measures to prevent the deletion of that metadata resource
… opt#1 we do that, continue to do. what we have been doing for a while. strict one to one relationship
<gb> Issue 1 not found
acoburn: wanna define a required content type, what is allowed by an allowed header
… alternative - like option 1, but diff media types that are implementation dependent
… option 3 - a client is in control of the metadata resources, we've defined mechanism to do that
laurens: not define it, and create metadata resource and add link header
acoburn: i dont like option #2 but i thought I would put it in there
<gb> CLOSED Action 2 reach out on Solid-related chat rooms on Gitter (on jacoscaz) due 2024-11-25
laurens: I would go with opt 1
acoburn: what ilike about text/turtle. very flexible. best rdf.
… if we josonld people might be wanting to have arbitrary data, but what does in mean in a json ld frame and interop suffers
<Zakim> elf-pavlik, you wanted to ask if it can have dedicated content type and or profile
acoburn: if we say text/turtle we have high level of interop
elf-pavlik: if we make turtle, you have possibility of composing those resources
… each presentation has a diff representation link
… some things we can do by collapsing by a single uri, but many diff representations are allowed
gibsonf1: in our case it would all be one resource, it makes no sense to have diff rep
… we are not having 5 different resources for diff versions
https://
elf-pavlik: what requirement says this?
gibsonf1: but you can specify the database
elf-pavlik: lws doesnt so that
… theres nothing constraining you from doing that
acoburn: weve had this convo a couple of times
… we are defining URIs for resource
… an entity that has an uri and you can perform different operations
… we have certain requirements
<Zakim> termontwouter, you wanted to ask about conformance reqs
gibsonf1: thats fine but maybe we should clarify that in the spec
termontwouter: the data resource itself can be accessed by another uri. there is nothing said that they have to be different
… so the idea that you could have both systems do content neg or various uri, i really like that
… i wonder if we should make one of them authoratative
pchampin: be clear that wehn we spec a resource, we are specifying a behavior and a interface but not saying how it is implemented
ACTION: pchampin to provide examples for this
<gb> Created action #146
pchampin: im concerned about the overlap, i think it can be confusing
… only non rdf resources have the aux uri as it would be confusing otherwise
… i wouldnt fight for reinstating this in LWS
<Zakim> TallTed, you wanted to suggest "must be available as text/turtle (optionally as other media types)"
tallted: suggest, rather than it must be turtle, it must be available as text/turtle
… so you can store it as oatmeal...as long as client can request turtle
<Zakim> termontwouter, you wanted to propose profile field for metadata format
termontwouter: provide alternative profiles that are available for a metadata resource
… as a server, if it wants to block this just give an array
elf-pavlik: if you have descr resource and non descript resource...you would get the same thing..does the server keep them seperate?
<Zakim> pchampin, you wanted to propose a crazy idea to solve the LinkSet vs. text/turtle
pchampin: dont know where people stand on this
… the linkset is aux resource in that its lifetime is bound to its main resource
… would if we merged them
… the expressiveness is a superset to this
… i expect this to be part of the link headers
… we could potentially CN this
<gibsonf1> +1 on two birds with one stone
pchampin: have turtle in a specific pattern to describe the link headers in turtle
… there would be constraints of course
… anything that has an uri would be included in the link headers
… i appreciate i cannot include arbitrary rdf like blank nodes
<TallTed> I think that merging in that way would demand a lot more from the implementation, and dictate more about how implementation is done.
<Zakim> termontwouter, you wanted to point out LinkSets not supporting literals
acoburn: turtle is superset of whatyou can express as links
<Zakim> acoburn, you wanted to talk about the challenges of merging linksets/aux resources
acoburn: adv of linksets and producing headers...having both headers and a linkset resource...useful when you have binary content
… want to see binary resource and the headers in some way
… or where you can go to get more info about resource
… that def is more expressive
… you will always have that second jump
pchampin: main added value of linkset is that you can have them appear in the link headers
<Zakim> elf-pavlik, you wanted to ask if certain links have to point to resources in the same storage
elf-pavlik: understood rdf is optional
… for linkset itself, some of the links describedby, probably restrict that they can only point to something in storage
… this would not be fully server managed
… that there would be very specific things that you could add
… there are pros and cons in either
laurens: one of the reasons I would be concerned with merging
… you would come into the situation that some resources that are both resource an container and you would end up with the same issues
<elf-pavlik> +1 laurens
pchampin: probably not worth it
<Zakim> termontwouter, you wanted to let the server make that choice
termontwouter: laurens for you the linkset is server managed?
laurens: it is both
termontwouter: what is client managed part?
laurens: add link relations to clarify types of content or profile
<Zakim> gibsonf, you wanted to ask on server vs user managed data
elf-pavlik: or the parent relation
gibsonf1: are we talking this in the spec specifically?
acoburn: with linksets. enough constraints around the rep. some server some client. totally easily to handle
… one that is def server manage is the linkset resource itself
… if client could change it, that would be odd and break things in weird ways
… i would block that
… i would probably allow just about any other operation
… promote a data resource into being a container resource
… subject to implementation constraints
… for the most part, a linkset resource is almost entirely client managed
termontwouter: do we stand in lws the link for optional metadata resources?
acoburn: for me, the hierarchy of preference. define the linkset resource.
… and i think we are generally aligned with how that works
… having more the kind of metadata you can have
… one could create description resources...
termontwouter: creating the link, make it managed
laurens: we have 20 more minutes
<Zakim> termontwouter, you wanted to propose required linkset but optional metadata resource(s)
<Zakim> pchampin, you wanted to propose to define "auxiliary resource" AND "metadata resource"
pchampin: the last discussion moving to option 4 (say nothing)
… there are other aux resource,m linkset, acl, we do have a variety of aux resources whos lifetime is bound
pchampin: interesting notion to have them automatically bound and managed
… last point, the notion of aux resource could use a defined header to indicate this
laurens: on one hand we have a def issue, defining aux resource.
… on other hand, what we have currently, clarify separation between linksets and aux metadata
ACTION: termontwouter to clarify the distinction of a linkset being an aux resource and other aux resources and clarify in the terminology
<gb> Created action #147
laurens: gives linkset resource definition
… they are bound in lifecycle to the primary resource
acoburn: do we have alignment which options we want to approach with metadata resources
elf-pavlik: mention that in opt 4, if we have the describedby we have the automatic management
… which would be server specific but contained in that container
… also in solid, access control applies to it
… we need to keep all the connected systems
laurens: we need to carefully consider that
<Zakim> elf-pavlik, you wanted to suggest advertise container for desc resource
termontwouter: if we have the metadata resource as a separate branch, we could position it how ever we want
gibsonf1: on term part, if you could switch back to that
… there is an interesting problem, the aux resource, that they be in a container?
… why couldn't the belong in a container?
acoburn: last oct, but the key thing here is that there is resource
… sep from your basic container, contains two diff items. also has these pointers to metadata resources
… the metadata resource are not included in the return of container contained resources
gibsonf1: need to include a line that the aux resources cannot be contained
elf-pavlik: do we need to make an exception here
laurens: fair points and they need to be discussed
acoburn: propose - i open a PR with this terminology and we continue to iterate on terminology.
… just do terminology
… i will include all of these
… controller or storage manager?
<gibsonf1> +1 controller
<gibsonf1> controller and storage controller
laurens: people will confuse it that controller doesnt entail any legal value
… problem is controller is a nice term to use
elf-pavlik: social applications cannot won social data, only social agents can
… this distinction is useful
laurens: fine with controller but just make the clarification
https://
acoburn: i will use controller....i will use that
<pchampin> +1 to qualify "controller"
Containers
<laurens> w3c/
<gb> Pull Request 83 Multiple Containment for LWS Containers (by laurensdeb)
laurens: we can get two easy things out of the way
… I'm inclined to close it, currently there's a single container hierarchy, multiple containment weakened that assumption
… it would allow to have multiple parents, it defines operation to manage containment, parent could be modified
… that my be desirable property in single containment as well
… two votes, on to close that PR and second to cherry pick that operation
… move operations have complicated semantics, for example authoriztion
termontwouter: i agree to try preserve the move feature
… i agree that lws should be single parent hierarchy
… we should publish/display different type of relations that are not lws:contains and still allow hierarchies
<Zakim> pchampin, you wanted to suggest a stronger resolution than "close 83"
pchampin: to suggest how to frame this resolution
laurens: yes we want to define it as out of scope
<Zakim> jeremycaine, you wanted to ask move data resource from one container to another has implementation impact such a 2PC
jeremycaine: the concept of moving data resource between containers, sounds good and has implications on implementation
elf-pavlik: no matter that it would be within one storage?
<TallTed> ACIDity
jeremycaine: yes since they could be stored in different places
elf-pavlik: +1 to preserving the mechanism for moving, it is a big shortcoming of Solid
… regarding the impact on permissions: we should consider existing systems
laurens: the issue is: when is someone allowed to move a resource in a different content
elf-pavlik: should be the same as the permission to delete it from one place and create it in a different place
laurens: that needs to be defined
<Zakim> termontwouter, you wanted to talk about authorization
termontwouter: i agree that it may not be such a big issue if we define auth etc.
<Zakim> acoburn, you wanted to talk about linkset modification and server constraints
acoburn: i like the idea of patching the linkset to move resources, are we propose to require it or just don't disallow it
laurens: we can have two votes, i would see it as optional
acoburn: i coudl imagine if you have lws with no slash sematics i would imagine it easy, if it is also available in some future specifiation eg. Solid
… if they require slash semantics, now we get bizzare behavior if we require it
<laurens> PROPOSAL: To keep multiple containment out of scope for the LWS v1.0 protocol.
acoburn: we shouldn't require it if it stops adoption
<gibsonf1> +1
<termontwouter> +1
<pchampin> +1
<laurens> +1
<jeremycaine> +1
<eBremer> +1
<acoburn> +1
<ryey> +0.5
<TallTed> +0.5
RESOLUTION: To keep multiple containment out of scope for the LWS v1.0 protocol.
<laurens> PROPOSAL: To extract from PR83 an OPTIONAL mechanism for updating the parent container in place as part of the container operations in LWS, by updating the resource linkset.
<gibsonf1> +1
<ryey> clarification: acceptable for time / deliverable constraints; hope still to explore possibilities after reaching 1.0
<eBremer> +1
<termontwouter> +1
<laurens> +1
<pchampin> +1
<acoburn> +1
<jeremycaine> +1
<ryey> +0.9 (+1 for supporting; 0.1 for optional)
RESOLUTION: To extract from PR83 an OPTIONAL mechanism for updating the parent container in place as part of the container operations in LWS, by updating the resource linkset.
ACTION: laurens to make PR extracting move of resources between containers
<gb> Created action #148
<TallTed> *** 15 minute break -- resume at top of the hour ***
laurens: i have 11 container related issues, let's start with easy ones
… #135
<gb> Issue 135 Reconsider Strict Tree layout (by damooo)
laurens: i propose to close it, starting with label and closing in 7 days, do we need a vote
acoburn: lazy consensus, if opposed, please speak up
laurens: issue #137
<gb> Issue 137 Storage itself to behave as a Container (by gibsonf1)
gibsonf1: proposing to close
laurens: #90
<gb> Issue 90 Distinguish between Container and Data Resources in the metadata (by laurensdeb) [ready-for-pr]
laurens: it was raised by ben in PR ????
… we had discussions that go in direction of capabilities
<Zakim> elf-pavlik, you wanted to ask about discovery of this capability
acoburn: not to revisit, i think that it is something that LDP does and nice to do, if resource acts as container it should include link header to advertise it
<gibsonf1> +1
acoburn: this does not prevent resource claiming to be both
<termontwouter> +1
laurens: do we already have all needed link headers
acoburn: i think but I don't remember
laurens: i will assign it to myself
laurens: #114
<gb> Issue 114 TotalItems: count MUST be exact: propose to SHOULD (by bjdmeest)
laurens: there is a proposed change, looking for volunteer to open it
eBremer: i can do it
laurens: i want to discuss notion of deletion on containers and recursive nature
<laurens> https://
laurens: lws says delete can be recursive, it doesn't really specify anything more than that, it specifies recursion depth eg. invinity
… default is with reject with 409 unless header is present
eBremer: it's from WebDAV
laurens: is it sufficiently addressing #88 ?
<gb> Issue 88 Containers: specify behavior on deleting non-empty containers (by bjdmeest) [ready-for-pr]
laurens: it seems addressed
pchampin: i was wondering if we covered the case if i don't have authorization to delete everything under?
laurens: if client lacks auth server must return 401, it doesn't define it being atomic
pchampin: it is dangerous to leave it unspecified, but it makes it more complicated
acoburn: it has been described in WebDAV with whole locking model, we could refer to it without bringing it in
laurens: is it separate issue?
acoburn: i would leave text as it is, it is worthwhile to add some notes
laurens: there is specified interface, we may need to do some cleanup, i will response to this issue suggesting to look at what is currently in the text
laurens: let's go till :30 past
… #69 has combination of recursive deletion and virtual resources
<gb> Issue 69 (Recursive) resource/container deletion and virtual resources (by renyuneyun) [needs-discussion]
laurens: i would like to make decision on it, in some cases it is relevant, do we have time to specify it given our other concerns
… will anyone take it up? i can't do anything more at this moment
termontwouter: i agree with the last comment of pchampin, that it shouldn't be something that we define
<Zakim> acoburn, you wanted to talk about related work
<ryey> yes, I am
acoburn: Inrupt has done some related work, we keep it out of Solid hierarchy
laurens: it would be helpful to say that container contains data resources or containers but no other types
acoburn: imagine you have one or more resources, and you want to do some interesting transformation into composed resource
… think of it as a function
<Zakim> jeremycaine, you wanted to ask about virtual resources
jeremycaine: you have data resource, with uri pointing to something
… it could point to URL which is pointing to something
jeremycaine: data resource can point to anything
laurens: there is no defined notion of virtual resource
… could be anything, it could be managed by storage
ryey: i agree that is lack of definition of virtual resource, hard to decide what to do with this issue
… i generally agree with what virtual resource imply
… it may be possible to ???? the only problem is that the type of this resource would not be container and client would not know if it can fetch contains predicates
pchampin: we are conflating two things, we shouldn't define virtual resources, i would consider specific problem
… it says about client lacking authorization, if client is not allowed or can't delete resource it would be 403
… I probably can't PUT or delete, it would be another reason to prevent recursive deletion
… as soon as I can't delete something the recursive deletion fails
ACTION: laurens: to change terminology to extend from the not allowed on virtual resources
<gb> Created action #149
<Zakim> elf-pavlik, you wanted to ask about proposed restriction
elf-pavlik: about restricting containers to only contain Data Resources or Container, it might prevent some affordances
… I would rather explicitly define that a particular kind of resources CAN NOT be in a container, than say a container can ONLY contain this and that
termontwouter: i agree that we shouldn't use this issue to define it, you don't write representation of the resource but the transformation
… it is an interesting notion
laurens: i would like to unassign myself, we either open separate issue to first introduce virtual resources, we close until that time and reopen as needed
acoburn: can i recommend that before we close we say "deletion works just as currently define"
ACTION: ryey to open issue that defines virtual resources
<gb> Cannot create action. Validation failed. Maybe ryey is not a valid user for w3c/lws-protocol?
laurens: we have 4 more issues i'd like to discuss, most of them are by gibsonf1
… please go through them and check if still relevant
… we will still be discussing combination of data resource and contaienr
… #177
<gb> Issue 177 not found
laurens: is this going to be solved by terminology
acoburn: there is side component, depending if storage description a CID
Type Indexes
eBremer: features: allow listing of types in a system and where they are located
… one endpoint gives a list of types, subject to action control
… another endpoint/service to ask for locations for selected type(s)
… type index API gives list of types registered in system
… type index search: A client sends a list of types and retrieves locations for resources with those types
<Zakim> elf-pavlik, you wanted to ask about relationships to shapes
eBremer: min requirement is to index Link header types
elf-pavlik: good starting point, would support merging it
… this is an improvement over Solid type index
… ODI is working shapes. There should be a clean way to connect to shapes
<termontwouter> +1 to shape integration
elf-pavlik: no clear proposal for connection to shapes ATM
<Zakim> termontwouter, you wanted to ask where authz info comes from
termontwouter: design is good overall. The results depend on which types a client can access
eBremer: it needs to have some connection to the access control layer
<Zakim> laurens, you wanted to propose allowing indexing over link relations (in addition to type)
gibsonf1: an optional mechanism of supplying a (partial) text string (e.g. autofill) would be helpful
laurens: I like this approach. Could we also index other relations in the linkset?
<termontwouter> +1 for integration of other relations
eBremer: that was part of the original proposal, but was trimmed down
jeswr: does it make sense to have the interface for this be SPARQL?
pchampin: do you mean a very specific profile of SPARQL?
laurens: I would try to avoid a partial support for SPARQL
pchampin: a subset of SPARQL would be brittle
laurens: converting linksets to RDF would be necessary as a first step
… nothing prevents a server from supporting other query endpoints
eBremer: we could add other linkset headers, which would start to look like a JSON-LD frame
<Zakim> elf-pavlik, you wanted to mention SAI using grants for discovery
elf-pavlik: from SAI, access grants are used for discovery. Follow your nose from there
… no separate type index service
pchampin: example 11 (response from type index service) look like a container representation
… like a container with a list of unnamed types
… example 15 (query for person or container)
… does this mean the container has a link header with type Person or that they contain things the contain Person
… that makes the type relation ambiguous
… reusing the container format makes sense, yet it is very different from containers. A bit uncomfortable for that reason
termontwouter: I like the fact that we reuse the same mediatype
laurens: I also like the reuse of the media type
eBremer: are there concerns about using different JSON-LD frames?
… allowing this provides a lot of flexibility
… based on the spec, I would need to create the frame first (client specified)
<Zakim> acoburn, you wanted to ask about location properties
eBremer: would allow client to shape the metadata response.
acoburn: indexes were just added to solidproject.org/TR
… they use two different properties, instance and instancecontainer
… instance indicates resources of that type and instance container containers that contain resources of that type
… they are two different types of queries, we seem to conflate the two and can we pull them appart
… i want container that includes foaf:Person vs. all instances of foaf:Person resources
eBremer: you can request that you only have containers
acoburn: if you say container, i would think any container and the container itself has type foaf:Person
eBremer: i want to know the key areas for it
… i could ask for foaf:Person and container it would return nothing
termontwouter: can we let the server return a 'container' array and if it doesn't do that we get a list of items
acoburn: i think they are two different sets of questions
eBremer: if it makes it clearer we can do that
acoburn: on possible suggestion, where you say type=if you said instance=and the instance container being the container
… typecontainer=schema:Person could give all containers that have instances of type person
<Zakim> gibsonf, you wanted to ask about search results
gibsonf: this is something that graphmetrix has been working on
… a container can be type:Person
gibsonf1: graphmetix was working on something we call ???? container can be a person, you can do a search on type person and get top level container is fine
gibsonf: in terms of instance, when you do a type search you are searching for instances
gibsonf1: things can have many types, we have often 30 types on something
gibsonf: in terms of looking inside the hierarchy structure, the hierarchy can be quite deep
gibsonf1: you may want to scope your search inside of some structure
… for example inside of hierarchy look for something
gibsonf: often you might want to scope the query to a particular hierchy using an "in" operator
gibsonf1: eg. give me all the carborators on specific car not all cars
gibsonf: e.g. give me all carbeurators in *this* car, rather than in all cars
<Zakim> elf-pavlik, you wanted to suggest constraintedBy
acoburn: sounds like a nice feature
elf-pavlik: in terms of indexing over link relations, there is a CSS feature to perform this type of query
… we don't always want to query for containers that already contain resources of a certain type
… e.g. an empty container where we *want* to store future instances of type X
gibsonf1: you can use types to indicate that a container is for particular types
… you wouldn't call a container type=Person for a container where you want to store Person types
… but you might have a type of PersonCollection for the container
laurens: how do we move this along? Was the input helpful?
eBremer: I can take this feedback into the proposal and update
<laurens> https://
laurens: we have a google sheet for people to sign up for working on features/deliverables
… grouped into epics / editorial
Administrative tasks
pchampin: w3c process akidna - using for use case docs, but need reoslution for new deliverables
… we need to agree to use akidna for all new docs
<pchampin> PROPOSAL: the working group decides to use Echidna to publish all present and future TR/ specifications
<termontwouter> +1
<pchampin> +1
<laurens> +1
<acoburn> +1
<jeremycaine> +1
<eBremer> +1
RESOLUTION: the working group decides to use Echidna to publish all present and future TR/ specifications
laurens: would like to wrap up and set out roadmap for next months
… need to resolve identity, so put in the project task tracking
… i.e dedicate some time at a next WG meeting
… this week meeting:
… is there anything we need to look at re: notifications for Access Requests
… wrt Notifications - couple of points in the task tracking: splitting; client to server; and remove certain things
acoburn issue notion of service description as a SID #117
… wrt Storage Description - we didnt discuss capabilties
… general consensus to keep 'capabilities'
… Aux Resources - need to distangle current text, linked sets etc - one other thing is clarify
… do we need to define a Metadate Resource as an additional aux res
… it would be extra scope
… add system diagrams and pictures of containers etc
… editorial: terminology
… create a new issue for editorial re: former editors section
<gb> Issue 117 Clarifications around containers and roots (by kaefer3000)
acoburn need to add an introduction to the spec
jeremycaine: would be happy to write the introduction
acoburn: would like to clarify the connection to OAuth 2.0
acoburn: sort out Section 8 and 8.1
acoburn: section 9 normative stmt
acoburn: section 10 lws media type, content negotiation ... reword - two media types are equivalent
acoburn: pagination is in Section 10; move to a separate section Pagination
<jeremycaine> s/laurens would/laurens: would
acoburn: better define container parent, semantics of delete, move
@laurens: wrt TypeIndexs - Eric will follow-up and update proposal
<Zakim> acoburn, you wanted to talk about did:key authN suite
gibsonf1: Acces Grants and Type Indexes clarification
acoburn: would like to followup on merging authentication issues
… do we need section 11 json-ld
… other specs do not write out full json-ld doc
… section 13 not sure we need a section for unstable features
acoburn: where to publish ? to github pages (it does JSON-LD)
laurens: elf-pavlik can help with test harness and pchampin with test data
… will make gh issues from the google sheet tracker
… next Mon - holding a WG meeting?
consensus is to have the planned meeting
and confirm follow-up actions etc
laurens: propose to close meeting a few minutes early !
Thank you everyone :-)
laurens: next f2f will probably be TPAC