justinwb
commented
1 year ago In relation to https://github.com/solid/webid-profile/issues/66, I would like to argue here that the SAI specification, just like the WebID-Profile spec, tries to do to many things at once. This results in each of these things being more tightly bound to others than necessary, which violates the principle of orthogonality, and thus complicates expandibility and compatibility.
Personally I've never had any objection to dividing up the specification, but I'm not sure I completely understand the boundaries you're proposing. It would help if you provided a bulleted outline, including all of the current sections, and then apportioned them under your proposed specs.
It's also worth pointing out that there are downsides to breaking a specification up - so before a bunch of work is undertaken to do so, those (and any subsequent work) need to be enumerated.
In relation to https://github.com/solid/webid-profile/issues/66, I would like to argue here that the SAI specification, just like the WebID-Profile spec, tries to do to many things at once. This results in each of these things being more tightly bound to others than necessary, which violates the principle of orthogonality, and thus complicates expandibility and compatibility.
Lots of powerful mechanisms on the Web work because of relatively small specs being able to work together. I would therefore like to propose we do the same, and split this document according to the specific needs that it tries to address, in order to tackle them separately, informed by current practices, and in cooperation/merging with other drafts tackling the same problems.
I retake two of the possible separation of concerns I suggested in https://github.com/solid/webid-profile/issues/66, and add a third:
A primary document should focus on authorization and application registrations, as suggested in https://github.com/solid/webid-profile/issues/62 [and formulated under SAI section 5]. The goal there should be to provide apps with a simple step from the identity of a user to a separate (sub)sphere where information can be found pertaining to the user's relation to that specific app. In other words: the application registration becomes the Profile extended with what that specific app needs and is allowed to.
Following the definitely justified separation of type indexes, and the issues raised in https://github.com/solid/webid-profile/issues/65, a central discussion is remains how agents can discover where to access data. [Since SAI data registrations, as specified in section 6] are almost identical [to type indexes], [p]ooling the insights of both would prove much more valuable. Building this pooled insight on top of [1] is a must i.m.o.
The sections on Access Needs and Access Authorizations could form one or two separate specs, (abstractly) building on [1] and [2]. This might require some changes, but keeps open the possibility of extending or replacing any of the interoperability parts in a much more flexible way.