Repository: https://github.com/solid/specification - Technical Reports: https://solidproject.org/TR/
@/all To get the most out of spec/panel meetings, I propose to prioritise meeting agenda items along these lines:
- Announcements: General announcements, agenda review, call for scribe..
- ReviewMinutes: Review/approve previous meeting minutes
- ContinueDiscussion: Continue unresolved items from previous meeting
- PullRequests: Review open pull requests
- Issues: Take up existing issues
- Discussion: Community feedback and discussion
This is not a strict order and there is no strict time allocation for each. The group should make reasonable effort to touch all items with sufficient time, make sure to mark unfinished discussions to be taken up in future meetings..
If there is something else that should be covered or handled differently, please say so. We can update when there are significant changes to the way meetings are held.
<https://frederick.trinpod.us/@>
solid:account <https://frederick.trinpod.us/> ;
solid:oidcIssuer "https://trinpod.us"^^<xsd:string> ;
solid:privateTypeIndex frederick:t_72 ;
solid:publicTypeIndex frederick:t_6x ;
space:preferencesFile frederick:t_8d ;
space:storage <https://frederick.trinpod.us/> ...
It would be great if user could have append/read on those containers, but current solid spec would not allow user to create subcontainers etc in that case
as for protecting the resources in those locations, that would be entirely an implementation decision. One could also argue that users should be in control of their own data, and if they want to delete a container called /inbox/, they should be able to do that
agree - this isn’t something for the core protocol to determine, but a matter of user choice.
@/all What does everyone think about only using quoted access modes for the WAC-Allow header? The current ABNF for WAC-Allow makes the quotes optional eg. user="read" and user=read are both valid. This was intentional. However, as brought up by @edwardsph in testing, if we take the ABNF as is, a parser that's following the ABNF as gospel could potentially generate unmatching quotes, and so it is not fun for clients to bother with something like user="read public="" . This would be silly and in most situations it would probably be considered a bug by implementations.. but it might be better to tighten this up... so to simplify client's parsing.
Aside: when I originally wrote the ABNF, I followed Content-Type's lead ie. allowing both quoted and unquoted values. However, those don't say anything about unmatching cases.. or factored in.
ABNF is supposed to be "aspirational".. so, we have a couple of choices. We can do one of the following (relatively complex to simple order):
- Update current ABNF to address unmatching quotes
- Update current ABNF to use quoted values only
- Leave ABNF as is (allowing quoted and unquoted) but add surrounding text for implementers to make sure not to generate unmatched quotes.
I think 2 or 3 will be fine. Slight preference for 2. 1 is overkill... and may still need some handholding with supporting text.
WOW, I guess I don't remember anything... since we already had this text:
The quoted and unquoted values for <code>access-modes</code> are equivalent. Servers are recommended to use quoted values in the response. Clients' are recommended to be able to parse both quoted and unquoted values.
Solid has the notion of containers to represent a collection of linked resources to help with resource discovery and
lifecycle management.
Are there any reference in solid spec to the lifecycle management. Is it within the containement triples with dates or etags .... Is there a W3 spec ? NSS use dates.
@bourgeoa In that context, "lifecycle" is as described in https://www.w3.org/TR/ldp/#dfn-containment . Happy to clarify this in the Protocol spec though. The intention is that a container gets to be aware of what happens to its resources eg. deleting a resource also entails that there is a cleanup task in which the containment statement is removed from the delete resource's container. There is also related requirements like disallowing a request to delete a non-empty container.
I'm curious to know what hinted at dates/etags for you though..
@csarven there where 2 questions : the first one came from solidos meeting where @timbl stated that in containement triples there should be date creation and date modified. I did not find any reference in solid spec. And the second was around the discussion in app-development chat around how to know that a resource has changed and where the first response was to check the body content.
If I may suggest that the solid specification give not only a global reference link but also to a paragraph link to the w3 specification.
Suggestion noted, thanks. I'm aware of the date info consideration about container resources in the container description.. will come back to this. (It is currently not a requirement).
For resource changes, yes, well, if authorized, and if present, Last-Modified or ETags are good indicators on each resource. To detect those changes from the container, yes, resource description (but again, if it is available.. and right now it is not required).
These containment triples are produced out of information available somehow on the server. Some of these informations should be available because solid is following the server http specification. For these one there should be no real cost. This do not imply that they must be available in containment triples and other may be solid specific not available from existing spec.
It is just an information in the discussion.
If you still feel inappropriate I shall delete my comment.