Meeting minutes
Introductions and announcements
acoburn: There is an editors draft for access requests and grants which we will briefly introduce. Most discussion should then by async.
… Pagination will also be covered.
… We will cover some open issues related to containers.
… Then a status update on the drafting of type indexes.
acoburn: Firstly introuctions
termontwouter: Most people here know me. I will be covering for the next few weeks as bendm cannot make the in person meeting.
acoburn: announcements
laurens: This is the last week of different timezones. Reminder to set your agenda in UTC which does not change.
Issue triage
acoburn: There are 5 new issues since last week. I have created 4 (#102-#105) to capture the work items discussed last week - there is nothing to triage on those.
<gb> Issue 102 LWS Test Suite (by acoburn) [work-item]
acoburn: ryey Please close #97 if it is not required.
<gb> Issue 97 Right approach to mark some likely editorial issues of the docs? (by renyuneyun) [propose-close]
Add editors draft for LWS Access Requests and Access Grants
acoburn: I opened #106 on Thursday last week, and did this with Luke
<gb> Pull Request 106 Add editors draft for LWS Access Requests and Access Grants (by acoburn)
Luke: This pull request is opened to discuss access requests and access grants. Prior discussions have taken place, including a resultant use of ODRL as a profile to describe the content of a request and grant.
acoburn: There is a discovery mechanism, data model, protocol, and notifications (which is a stub as we do not have a notifications system yet).
… Discovery says use the storage description resource, giving where you can find the service endpoints
… Access Request and Grant services have a `conformsTo` predicate which determines the data model of the access request/grant
… The only requirements in the protocol is that access request and grant endpoints must be LWS containers
… There is some guidance around authorisation which could definitely use some editorial attention
… The Data Model attempts to be fairly simple, to be able to cover a wide variety of use cases without being too complicated to implement
… Noting that there could be different access policy languages under the hood of the server
… There are many use cases so some servers may need more expressive access requests to be given to them
… That is what the conformsTo predicate is for, it allows you to define different profiles.
… The default profile that we have is all basically ODRL
<pchampin> https://
acoburn: What we have is basically an ODRL rule, what we have tried to do is take as small ODRL profile as possible without requiring too much from implementors
<pchampin> https://
acoburn: All terms within the access object in the default data model are all ODRL term; with the exception of hasPurpose which comes from DPV
… One thing to point out is that target is currently quite limited; as the target is a URL
… The target property identifies the resource, it really needs to be improved. We need to allow for there to be a JSON object in the target so as to not have just URIs of resources that are targeted.
… I should also point out that I would hope there is not a proliferation of too many profiles for Access Requests/Grants
Pagination for LWS Containers
laurens: I am discussing #82 - pagination for LWS containers. This has been open for some time.
<gb> Pull Request 82 Pagination for LWS Containers (by laurensdeb)
laurens: I don't see any remarks left on the content of the PR barring bendm's comment from 10 minutes ago
… Alternate wording is welcome for that comment
… gibsonf1 Identified that it may not sufficiently cover LWS Use Cases. I don't think opaque links are an issue, query parameters for instance can still be used
gibsonf1: After discussing this with TallTed, I am not opposed to the opaque links; just not as many in the example.
… In other words 'less is more' on this
<pchampin> +1 to only require the `next` link
laurens: I have already update to only require first and next links
gibsonf1: And those could theoretically be generated based on the user request
laurens: Yes.
<Zakim> bendm, you wanted to ask for pagination: that's an (optional) capability, no?
bendm: I this a capability of a server, or a core functionality of a server.
laurens: I interpret as an optional feature to support pagination on containers.
bendm: So it could be possible for pagination to not be as defined here, but for a server to then e.g. query instead
laurens: There is no restriction on how a server performs pagination. The only think we normatively require is that thesee link headers be present
pchampin: In terms of describing this as a capability. Servers are always free not to implement it as there is a server defined threshold, which they could define as infinity and thus never follow those links
… Clients should never have to check if a server has this capability
<bendm> +1 on all the things pchampin said :D
<Zakim> gibsonf, you wanted to ask about pagination context
gibsonf1: I am thinking it might be better to call it pagination rather than pagination for containers. Type search, for instance, will need to refer to this as well
<Zakim> acoburn, you wanted to ask about mechanisms for advertising pagination behavior
laurens: I can follow that, and the access request/grant spec will have simlar needs
laurens: I would view it as a default capability of the server to have the parameters defined in this PR. Additional capabilties that could be layered on top of pagination are other query parameters
<gibsonf1> +1 on pagination not being optional
TallTed: The challenge when making a feature optional, is that you still have to let the communication componentry has to be able to discover what is enabled. This is why I have been referring to the scrollbook implementations on ODBC and JDBC. We should not re-invent this wheel. We should pay close attention to how it has been done elsewhere; and
… the terminology should be re-usable.
… In my mind there is a question of whether pagination is even the right term. Before giving me the list I should be able to ask "hey do you support cursors or windows etc." so that a client can say if it supports this thing, and if so, what kind it supports.
… The most basic cursor is a forward only, often you will get a window which you can specify but not always
… Generally with forward only, you can only move forward by the window specified, but not an arbitrary one which you choose.
… This ensures that parcel support is enabled by both ends of that connection
laurens: Concretely what would you want changed in the PR if anything
TallTed: I would have to read the PR more carefully, I am not prepared to give a full specification on this thing.
laurens: I propose that we merge this PR, addressing the two changes opened during this call.
<pchampin> TallTed, the current proposal is agnostic to how the "next" link is constructed, or pagination handled by the server; so I think your suggestion applies to potential additional capabilities, but not to the PR as it stands
laurens: I would like to make a vote next week.
acoburn: If you plan to review this, please do so.
Container-related Issues (#72 ,#69 ,#71 ,#86 )
acoburn: There are 4 container related issues which we can either resolve now, or make a plan for resolving - #69, #71, #82, and #86
<gb> Pull Request 82 Pagination for LWS Containers (by laurensdeb)
<gb> Issue 71 Make Resource identifiers really unique within the system (by gvseghbr) [needs-discussion]
<gb> Issue 69 (Recursive) resource/container deletion and virtual resources (by renyuneyun) [needs-discussion]
<gb> Issue 86 Have separate auxiliary resource for containment index (by damooo) [needs-discussion]
acoburn: #69 is related - but on the side of container things. There has not been a lot of conversation since last month
laurens: This goes to a remark which is already in the text, that containers must point to other containers/resources in the same storage. There is no current notion of virtual resources.
… It is more to do with how we define a resource in LWS, and whether it should live in a conainer.
ryey: I agree with the summary. I will try to find where all those use cases were located. I believe I proposed some of them when we were collecting use-cases a year ago. I will try and find some of them this week.
acoburn: One thing that might be helpful to clarify is right now if the specification requires that a container must be a data resource or another container -- is that too constraining for such use-cases. Could it be possible that there is another type of resource that is a member of a container. Would that be helpful; or just muddy the water?
… Either way, I think we can set this one aside, and ryey can add additional comments
<Zakim> gibsonf, you wanted to ask about container that is a data resource as well
gibsonf1: Can a container also be a data resource
acoburn: It is currently a disjoint set. A container has certain requirements which are distinct from the requirements of a data resource. There is nothing explicitly saying a container cannot be a data resource -- it is just an implication that it cannot.
gibsonf1: A container resource can often be, and many times is, a data resources
… there are many examples of containers in the real world. A bowl which has water has attributes and information about it.
… If they were disjoint. It would make what twin pod is currently doing impossible
… When you make a request about a container, you get a representation. As opposed to data representation
… That is why I have also been talking about resources, auxillary resources - etc.
acoburn: This sounds like issue #86 which we will get to in a minute
… From my perspective, a container as an abstract thing could have all kinds of different forms. What we want to clarify is what an LWS container requires.
… What damoo describes is that currently in LWS we currently have a strict restriction on what the requirements are for an LWS container -- wheras an LWS resource can do whatever it wants
… One of the benefit of clearly definining resources on containers means that you can clearly define operations; and the representation is also fixed
… damoo suggests a resource could have an arbitrary type of representation (e.g. XML).
… I think there is a lot of interesting stuff there. If he treats this cotnainer as a data resource with extra features, then the same thing is opssisble without going in a very different direction. This means defining containement in a very very different way. Including ways that are not currently implemented.
… I think we should take this idea and get more maturity.
… I don't think LWS should suddenly veer in this direction whilst it is imature.
gibsonf1: I am not a fan of talkinf about auxillary resoruces. I would need to get on the same or dierent URi.
… I want to make sure that on a request I can get the same response as a content resource.
… The current sec doesn't prevent content negotiation (though it doesn't require it).
gibsonf1: Therefore I thin we should talk about representation, not resources.
acoburn: This already differes from the HTTP sepecification
gibsonf1: I think it wouldn't hurt anything to talk about, for an LWS container, the representation is X
ryey: The current specification seems to be too restrictive in 2 ways. (1) a contained thing must be either a container or a resource (2) the metadata for those virtual resources are not necessarily known to the server at the time they are queried. I would not mandate the server to query those information (from whatever is responsible for the virtual resources) before responding to the user due to performance considerations
acoburn: If you have comments please leave them; I would like to resolve these issues sooner than later.
<eBremer> https://
acoburn: Could the people working on type indexes also report
eBremer: See link posted