-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
About descriptive and normative documents #68
Comments
It's likely that we will have both normative statements and best practices statements. We are revising the current document based on feedback about conformance rules. Please watch upcoming PRs and flag any you object to.
The fact that we base ourselves on current practices is not mutually exclusive with any of those things and if you look over our meeting notes, you will see we've done a lot of that.
That's one opinion. Most specifications I can think of include both normative and non-normative text.
And ignoring them would promote chaos and not provide a path forward since things always start where they are. |
That is true, but the fact that you base yourselves on current practices only is what bothers me. That is exactly what the minutes show: you start in current practices, select the one you think is best (granted, through rational argumentation), and possible fine-tune a bit here and there. What a spec should do, is to formulate a goal (other than "describe what's there"), start in that goal, and compare current practices with theoretically interesting models.
Of course, best practices and non-normative text is valuable, I never denied that. What I am complaining about is the use of descriptive text AS normative text. A sentence describing how things are CANNOT also specify how things should be, simply because these things are (often) not the same. It is this incompatibility of norms and descriptions in the WebID-Profile "spec" which endangers the progression of Solid. Making the descriptive normative, i.e. recommending to do exactly as things are, not only creates a standstill for implementations following this "spec", but also renders them uninteropperable with implementations that do not follow it (as pointed out by a.o. @RubenVerborgh, @elf-pavlik and myself in relation to WebID-Profile, SAI and TypeIndexes).
Where did I say we have to ignore current practices? As I've stated in multiple comments in this repo, compatibility with existing implementations can definitely be a concern. But "compatibility" does not mean "make current practice the norm"; it means "make sure that current practice still works acceptably with practices fully implementing the norm." As I've pointed out in #65 (comment), I have up till now not seen a clear argument why compatibility with current practice cannot be achieved by a radically different norm. In the extreme, we could do all discovery out of band, pay people to manually check each "old school" WebID, and still be compatible with current practices (though this would of course fail any sane test of efficiency). |
In summary, what I mean is: let's stop worshipping current practice as the norm (WebID-Profile) or building theoretically elegant models without concern for current practice (SAI), and bundle our efforts to find a way to combine the two. This is i.m.o. best done by splitting up into focussed mixes, as argued for in #66. |
There has been some confusion in recent discussions (#64, #65, and the gitter channel) about the nature of the document being drafted here. I have already tried to address this in #66, but it might be a good idea to treat it separately here. I repeat the most important part:
To give some examples of what I mean, statements and arguments around this document go like this:
That should suffice in giving an idea.
Now there are two things I want to point out with this approach. Firstly, there is nothing wrong with compiling an descriptive overview of current practices. To the contrary, such document would be very informative. Secondly, however, it IS wrong to conflate this with a normative specification.
Descriptive documents ... describe the current state of affairs. They don't bother thinking about the future, because they don't have to. Having normative statements in such a document would hardly make sense, unless maybe as some kind of notes to inform another separate normative document. Specifications on the other hand start from aims, compile use cases, construct a model, and mandate specific requirements based on rational arguments, in order to reach those aims. While current practices can be of concern for compatibility issues, they typically are not the primary factor of influence, definitely not in draft stages. Relying too much on the current state of things would ultimately never allow improvements to be made.
Since the above makes clear that both goals are at least partially contradictive, and should therefore ideally not live in a single document, it is rather worrying to read phrases like "[to] make recommendations," "[and] pointing out how things can be better," and "this specification aims to describe [...] as it is currently in use," in a so-called descriptive document, which also contains normative sections and conformance terms. This reads almost as if a set of practices employed by a limited set of users is being pushed on all the other users.
I would therefore ask of the contributors of this document to clarify whether it is
The text was updated successfully, but these errors were encountered: