Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[tsf-dev] TSF process feedback - part 2 
The follow up to the last email.
It's worth thinking about what TSF is claims to do at a high-level. I think the optimal way to do this is evaluating TSF through a self-referential lens. If I were applying TSF to itself, what would the top-level claim be: "TSF ...".
From my observations there exists a spectrum, the two ends of which I will outline: 

On the one end: TSF as a flexible narrative framework.
- TSF exists to input claims, metadata/descriptions and evidence into a model. 
- All claims are freeform text, and not machine interpretable.
- TSF does not make any inferences.
    - There is no explicit logical structure.
- TSF cannot evaluate how true any claim with a mechanical decision procedure. - TSF presents/displays information and evidence to convince the audience to make interpretations themselves. 
    - Is as descriptive as possible, to be as persuasive as possible.
On the other end: TSF as a stricter framework for making valid arguments. 

- TSF requires you to make a valid argument.
    - https://en.wikipedia.org/wiki/Validity_(logic)
- Given the argument is valid, TSF can evaluate soundness.
    - https://en.wikipedia.org/wiki/Soundness
- TSF can evaluate the truthfulness of claims deductively.
- Text is expressed in a structured language such that the "meaning" can be derived by machine.
I may have missed bits and pieces, but I think that covers the core principles at each end of the spectrum.
From what I understand (I am happy to be corrected), TSF began as the former. Geza's proposal @ https://gitlab.eclipse.org/eclipse/tsf/tsf/-/merge_requests/596 represents the latter. Both have their merits, require tradeoffs, and are target different audiences/domains.
I think, given we started at the former, the introduction of the "score" shifted (probably unwittingly) perspectives/expectations towards the latter, leaving TSF in a grey area, where interpretations can be made on fallible foundations. I don't know in this situation there exists a happy middle ground. 

Worth considering in the context of TSF:
TA-EXPECTATIONS: Documentation is provided, specifying what XYZ is expected to do, and what it must not do, and how this is verified. 

Best Regards,

Nathan

Back to the top