Minutes 2023-11-15 #597
Minutes 2023-11-15 #597
Conversation
| * PA: We received a [review](https://github.com/w3c/strategy/issues/377) from the TAG, which echo some remarks from the AC review. | ||
| * ...: I don't know why we didn't get this review earlier, before sending it out to AC. |
There was a problem hiding this comment.
@pchampin , back in March (2023-03-22) I've requested for a TAG review prior to AC review in solid/solid-wg-charter#15 :
As part of horizontal review, review from TAG should be requested to improve the charter prior to going to Members.
This topic was also on the CG agenda at least 4 times: https://github.com/search?q=repo%3Asolid%2Fspecification%20path%3A%2F%5Emeetings%5C%2F%2F%20https%3A%2F%2Fgithub.com%2Fsolid%2Fsolid-wg-charter%2Fissues%2F15&type=code and undoubtedly mentioned numerous times.
So, I know you/we've acknowledged and discussed this issue.
Why did we go to AC review without TAG review? Who made the call?
I would also add that every single one of the other points/considerations I've raised in that issue are literally the feedback we've received through AC reviews.
Please let me know if/how I can be of better service.
There was a problem hiding this comment.
Why did we go to AC review without TAG review? Who made the call?
I request horizontal reviews on the charter back in June (see timeline of this issue). Some groups responded, others (including the TAG) didn't). It is generally agreed that we can "timeout" on horizontal reviews, in order to keep things going.
In retrospect, I should have chased up the TAG in order to get their review... 😞
| * ...: making this a successor of LDP would make this less about this being a special way to solve very large problems | ||
| * ...: This also would address the criticism that we are extending something existing rather than specifying something particular from Inrupt | ||
| * eP: This seems like a pragmatic approach to consider. There has been movement to make Solid _not_ a direct successor of LDP | ||
| * ...: A good step might be to document that prior work and how Solid differs from LDP |
There was a problem hiding this comment.
Along the lines of https://solidproject.org/ED/protocol#relationship-to-ldp .. #224 ? I am well-aware that there is more to the story.
On 2023-07-03, I wrote the following for that section introducing Solid Protocol's relationship to LDP: #539 (comment)
It is intended to help W3C horizontal reviewers ( e.g., solid/solid-wg-charter#15 ) as well as anyone already familiar with either Solid Protocol or LDP (or both) to understand where they come together or diverge.
See also https://github.com/solid/specification/pull/597/files#r1394432591
/cc @pchampin
There was a problem hiding this comment.
My understanding (still after re-reading the "Relationship to LDP" section) is that Solid storage servers are complying LDP servers, with some additional restrictions that Solid clients can rely upon. Such restrictions have been introduced by the Solid community for good reasons, so they could be considered either as
- improvements over LDP 1.0, that all LDP 2.0 servers should comply with, or
- a specific profile of LDP which could be specified (but not necessarily required) in LDP 2.0.
There was a problem hiding this comment.
My last comment on this PR :) We should continue elsewhere.
- improvements over LDP 1.0, that all LDP 2.0 servers should comply with, or
You know.. this is hard. And will take a dedicated Group to do just that. And LDP Next CG would've been the place. Perhaps it could be reopened if there is new interest.
- a specific profile of LDP which could be specified (but not necessarily required) in LDP 2.0.
I think this would've been good to defer to the LDP Next CG for anything that would resemble LDP 2.0, as opposed to Solid Protocol. This is why I proposed to add LDP Next as one of the groups to coordinate with in the WG charter ( https://github.com/solid/solid-wg-charter/pull/12/files#diff-338e19e28f599d3bc3f239af866c9bf1fdcdfdb2e35d7806baffb4bc1ce7ea5bR410-R411 )... and follow-up with the LDP Next CG at the time: https://lists.w3.org/Archives/Public/public-ldpnext/2023Mar/0003.html ... but unfortunately the group recently closed (2023-10-16) : https://www.w3.org/groups/cg/ldpnext/ . This is tiring. I mean.. again, there is even https://fcrepo.github.io/fcrepo-specification/ based off LDP too (and even using/referring to Solid stuff like WAC and LDN.)
I (we?) know that LDP 1.0 doesn't cut it for Solid. We understood that ago, and it only technically / explicitly borrowed some parts. We tried not to introduce any conflicts though. Neither LDP or the Solid Protocol doesn't quite cut it when it comes to utterly simple, and by far the most dominant use case out there e.g., a homepage / a representation of some sort to express an identity (no, I don't mean WebID) / aboutness / general index on the root container (root URL path with /). LDP and Solid Protocol doesn't / clearly explain that out of the box (yet). We needed more implementation experience. In the case of LDP, that wasn't even really taken into account as a UC, AFAIK. In the case of Solid Protocol, some folks seemed to have HTMLphobia and well, we got caught up with conflation of personal preferences with needs and technical feasibility. I've lost track of the number of times where I said: we will not get Solid adopted / or lose a lot of people, if we don't show a clear path on how people can publish/manage something like a homepage using the Solid Protocol consistently, just as with any other resource. And, no, a homepage is not an application for the most widest use - It doesn't not require JavaScript to be human-readable/accessible. That said, I'm confident that this can be resolved.
Any way, the Solid Protocol Server would generally be compatible with LDP Server ( https://www.w3.org/TR/ldp/#terms ) - as far as the role is concerned based on HTTP server - but none of the major LDP requirements besides some behaviours related to basic containment. (I don't wish to dive into those details here. As mentioned in the PR that introduced the section, that can all be spelled out further (brief mentions in https://solidproject.org/ED/protocol#server-basic-container and protecting containment statements etc..) Don't get me wrong, there is high overlap and it is relatively easy to extend an implementation conforming to an LDP server to conform to a SP server.
There was a problem hiding this comment.
Let's keep in mind that this PR will be merged and closed. We should probably track it in an open issue rather than here.
There was a problem hiding this comment.
@csarven I find your anecdotal case against LDP vague and unconvincing. Especially as homepage is nowhere mentioned in the charter or your spec, indeed neither is HTML. I suspect you are lobbying for your minority view position of using RDFa + XHTML. Conversations in the WebID CG lead me to suspect that will be removed from WebID in favour of JSON-LD. @elf-pavlik is correct, this should go in a new issue in the charter repo. There is a path to standardize LDP 2.0 as the basis of Solid 1.0. Let's examine the options in a proper github issue.
There was a problem hiding this comment.
Hey @melvincarvalho , nice to see you here. How are things? What you wrote is mega deep, true, and insightful. You should run for chair or table.
There was a problem hiding this comment.
Hey @melvincarvalho , nice to see you here. How are things? What you wrote is mega deep, true, and insightful. You should run for chair or table.
@csarven this is completely inappropriate
There was a problem hiding this comment.
Melvin, please seek my confirmation instead of assuming and sharing your unsolicited speculations and claims regarding my lobbying. Just a hint: you're completely mistaken.
Furthermore, you don't have consent to speak on behalf of or represent the views of the Solid CG (and the WebID CG).
Once more, I encourage you to review the Solid CG's communication guidelines.
There was a problem hiding this comment.
@csarven your response is completely inappropriate.
Co-authored-by: Ted Thibodeau Jr <[email protected]>
No description provided.