Is output.json part of this syllabus? It's a new feature, so is it just forgotten or intentionally left out?

@asimell no. its not yet. also xunit.xml and legacy output is not.
only the standard.

• If the Keyword Teardown fails, the test|task is marked as failed in reports and logs.

no. see setup

Each subsection for different argument types would benefit from one or more examples. Probably example of libdoc keyword documentation would be enough. Currently, this is probably one of the most abstract sections of the syllabus. In theory. In practice one does not really need to think about these (outside designing and implementing keywords, of course).

I must acknowledge that the chapter starts with examples, but those are far away from the detailed per argument type sections.

Should the syllabus also explain the exam a bit? As in how many questions it will have, what types of questions, weight on different question domains, etc.?

Should these follow the general best practices that all suite variables are in upper case?

Glossary should probably be sorted alphabetically (seems was so in the beginning but then got mixed).

second that- common practice for appendices

Before K2 (Understand) objective for conditionals and iterators, it's probably worth adding K1 - recalling objective (first know what it is, then understand each one).

For example,
Recall at least three control structures available in Robot Framework,
or something similar.

Punctuation seems inconsistent - some sentences in the table end with period ., some - without.

This was not super clear to me what does it mean "while variables need special syntax".

Tried to explain it like so:

Variables in Robot Framework must use ${variable} syntax, while plain text like Hello World is automatically treated as a string without needing quotes.
The ${variable} syntax tells Robot Framework "this is a variable, use its value" rather than treating it as a literal string.

This sounds painful to my English ear:
"and except of the"
Should be:
"and apart from the standard libraries are not part of Robot Framework itself"
But that also sound horrible because it contains "apart" and "part".
Maybe something like:
"Keyword Libraries are collections of Library Keywords that are implemented in Python or other programming languages. While standard libraries come bundled with Robot Framework, most Keyword Libraries are external components that must be installed separately."

I think this sounds better as:
"until the defect is resolved."
OR
"until the defect has been resolved."

This is a bit weird because it talks about two types of variable then mentions three

1. Statically defined
2. Imported
3. Dynamically created

there are two bullet points.
Statically defined and imported variables are one type.
Dynamically assigned during execution is the other one

Glossary has Libdoc and Rebot but not Robot
i.e.
https://robotframework.org/robotframework-RFCP-syllabus/docs/chapter-02/executing

Somehow I think in the glossary Rebot is mixing Robot and Rebot.

Should "automation tasks" be "robotic process automation (RPA)"?

Reorder:
1.5 Licensing and Foundation and Web pages
to match order

Maybe
However ordering means renumbering of LOs which is a massive change!

We should use a standard tree diagram here as found in markdown.

example: https://www.w3schools.io/file/markdown-folder-tree/

This is difficult to read.

#I would have said something else beside locally:

This may seem verbose but it is easier to understand:
Corresponds to the [<setting>] setting.

ALL of the settings should be described as:

- <setting> Description

With each setting with its own line. i.e. break up the Test Setup / Task Setup from Test Teardown / Task Teardown

The user guide lays out these settings very well: https://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html#setting-section-1

A clear list of settings and definitions- very concise and consistent.

I placed all my main comments in the next comment.

It is good to have a paragraph of explanation of the settings section, but the settings should be clearly presented outside of a paragraph structure.

There is a concept of Advanced Variable features in the user guide: https://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html#advanced-variable-features

Not sure if the syllabus lines up with the user guide.

no. but for the syllabus this here is advanced stuff.

second that- common practice for appendices

I would avoid the use of 'skipped' here, it is ambiguous. Instead mention specifically 'NOT RUN' as that is what keywords get assigned as a status when a previous keyword is given a "FAIL" status.

Won't the 345foo__FirstSuite.robot suite file set the name FirstSuite in your correction?

Won't the 345foo__FirstSuite.robot suite file set the name FirstSuite in your correction?

Yes, you're right! :-)

It may be possible to use this characters in the prefix, but we are not obligated to mention every weird thing that is possible.
So i do not see the benefit of overloading people sith this level of detail/possibilities.
I think the numbering is the most used and obvious option.

I would suggest to use a consistent style for all the variable names:

• ${EXECDIR}
• ${EXEC DIR}
• ${EXEC_DIR}

tell that pekka and not me ;-)
Call Get Variables and be surprised. ;-)

In this section, I wonder if we want to mention the third 'Root Suite' that is possible. Someone that was being taught mentioned that Robot allows for 'multiple files / folders' to be added as per:https://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html#specifying-test-data-to-be-executed

When this is done. Robot creates a 'virtual' suite from which to generate the overview of suite files and folders. A quote from user guide:

The name of the created test suite is got from child suite names by concatenating them together with an ampersand (&) and spaces.

It might be a bit too complicated for 'RFCP level, but perhaps a mention of this thing might be necessary.