LG 1-1: Strengthen connection toward foundation level

[kuromogeko]

Hi,
Reading the curriculum I would appreciate if the starting Chapter 1 would pick up a little stronger on the foundation level terminology and refer to it.
While I am sure most training providers will do so by themselves, specifically mentioning "low coupling" and "information hiding" as architectural goals behind the usage of APIs would be much appreciated.

I believe adding this connection eventually makes it easier for participants to classify APIs in the field of software architecture and get a better idea of how and when to use them.

I could imagine it to be phrased as an additional LG as well.
"1-3: Understand how APIs are used to achieve low coupling" or "1-3: Usage of APIs to achieve information hiding".

Open for discussion on whether rephrasing 1-1, adding an LG or not moving forward with this proposal is the best for the curriculum.
(Since I currently can't imagine a different use for APIs other than low coupling but would see how its history might still provide value to participants different from only displaying it as a means...)

Glossary:
Participant: Anyone which eventually ends up in a iSAQB Certified API Training.

[dret]

This sounds like a good idea in principle. One issue may be that there isn't any "standardized terminology" in the foundation curriculum and it's not easy to figure out if and how various trainings are using specific terms in the same way.

But again, the idea is a good one and if you have any additional ideas we'd be more than happy to discuss. Maybe just create a PR and then let's discuss. Thanks for contributing!

[kuromogeko]

Yeah in theory there is a glossary which should make sure terms are used the same in iSAQB context .
Best we can do is probably try to adhere to it as much as possible and be happy with every instance where it works out.

I will create a PR.

Glossary link:
https://public.isaqb.org/glossary/glossary-en.html#_i

[dret]

Yeah in theory there is a glossary which should make sure terms are used the same in iSAQB context .
Best we can do is probably try to adhere to it as much as possible and be happy with every instance where it works out.

Now, that's interesting! I will have to see if we are or should be using any of the terms in there. Also, how does one contribute to that? Answering my own question, it's here: https://github.com/isaqb-org/glossary

[dret]

@programming-wolf, realistically speaking, should we go through the exercise of aligning API with the glossary? Should we start adding to the glossary? We could, but that seems like something we can do on an ongoing basis and for now stick to the terminology that we've used.

[programming-wolf]

You should use the same terminology that other curricula use (read: that are defined in the glossary), and definitely add important terms of your curriculum there.
It would be great if most of the terminology was aligned for the launch of the curriculum. You can add your terms there later of course.

[sippsack]

Even if it is a good idea to align this curriculum better to the foundation curriculum, it must not part of the first release. If proposals come in we can just discuss this further and merge them in future releases.

But we should definitely add some terms to the glossary which are relevant for APIs. I'll open another issue for that (#67).

[dret]

On 2025-02-10 23:05, Benjamin Wolf wrote: You should use the same terminology that other curricula use (read: that are defined in the glossary), and definitely add important terms of your curriculum there.

Anything or just those that are in the foundation and are not in the glossary? @gernotstarke seems to prefer to see mostly foundation terms in the glossary.

It would be great if most of the terminology was aligned for the launch of the curriculum. You can add your terms there later of course.

We'll do our best. For now it would be great to get clear guidance on whether we should add any terms that we feel are important, or just those that are in the foundation? Thanks!