Update syllabus docs for RF 7.5 concepts

website/docs/chapter-02/01_suitefile.md

@@ -142,10 +142,13 @@ Those settings are prefixed with either `Test` or `Task`, according to the type
 
 - `Test Timeout`/`Task Timeout` (locally `[Timeout]`) defines the maximum time a test|task is allowed to run before it is marked as failed. The local setting overrides the suite's default.
 
-- `Test Tags`/`Task Tags` (locally `[Tags]`) define tags that are assigned to tests|tasks in the suite and can be used to filter tests|tasks for execution or for attributing information to the tests|tasks. The local setting appends or removes tags defined by the suite's default. See [4.4 Test|Task Tags and Filtering Execution](chapter-04/04_tags.md) for more information.
+- `Test Tags`/`Task Tags` (locally `[Tags]`) define tags that are assigned to tests|tasks in the suite and can be used to group them, filter their execution, and create result statistics. The local setting appends or removes tags defined by the suite's default. See [4.4 Test|Task Tags and Filtering Execution](chapter-04/04_tags.md) for more information.
 
 - `Test Template`/`Task Template` (locally `[Template]`) defines a template keyword that defines the test|task body and is typically used for Data-Driven Testing where each test has the same keywords but different argument data. The local setting overrides the suite's default.
 
+Individual tests|tasks can also define their own `[Metadata]` setting with named key-value pairs such as an issue ID, author, or requirement reference.
+Unlike tags, metadata is meant for descriptive information with explicit names and values and is not used for test|task selection.
+
 Similar to test|task tags, also keyword tags can be defined in the `*** Settings ***` section with the `Keyword Tags` (locally `[Tags]`) setting, which can be used to set keyword tags to the keywords. The local setting appends or removes tags defined by the suite's default.
 
 
@@ -188,7 +191,7 @@ Test cases and tasks are technically synonyms for each other.
 However, users have to choose one of the two modes of suite execution that Robot Framework offers.
 
 Each test case or task is structured using an indentation-based format. The first un-indented line specifies the name of the test|task, followed by indented lines containing **keyword calls** and their possible **arguments** and test|task-specific settings.
-These optional settings like `[Setup]`, `[Teardown]`, and `[Timeout]` can be applied to individual test cases or tasks to control their behavior or provide additional details.
+These optional settings like `[Setup]`, `[Teardown]`, `[Timeout]`, `[Tags]`, and `[Metadata]` can be applied to individual test cases or tasks to control their behavior or provide additional details.
 
 A suite file must contain either a `*** Test Cases ***` or a `*** Tasks ***` section, but not both. Resource files cannot contain either of them.
 
@@ -232,4 +235,3 @@ All content in this section is ignored by Robot Framework and is not executed or
 
 
 
-

website/docs/chapter-02/05_keyword_interface.md

@@ -14,9 +14,9 @@ Understand the structure of keyword interfaces and how to interpret keyword docu
 Library Keywords and User Keywords that are defined in a resource file should have a documentation text that describes what the keyword does and how it should be used.
 
 Robot Framework is capable of generating **Keyword Documentation** files that contain a library- or resource-documentation, all keywords, their argument interfaces, and their documentation texts.
-This documentation file can be generated with the `libdoc` command and can be used to provide a reference for users who want to use the keywords.
+This documentation can be generated with the `libdoc` command and can be used to provide a reference for users who want to use the keywords.
 
-Basically all standard and external 3rd party libraries offer these Keyword Documentations as online available HTML pages.
+Basically all standard and external 3rd party libraries offer these Keyword Documentations as online available pages.
 
 Robot Framework offers the Keyword Documentation of its Standard Libraries at https://robotframework.org/robotframework .
 
@@ -44,11 +44,13 @@ Each library or resource documentation can contain the following information sec
 - **Return Type** (opt.): The type of the return value of the keyword.
 - (*) **Tags** (opt.): The tags that are assigned to the keyword to categorize keywords.
 - **Documentation** (opt.): The documentation text that describes what the keyword does and how it should be used.
+- **Additional structured details in the documentation** (opt.): Depending on the library and Robot Framework version, the documentation may also contain formatted examples, more detailed argument descriptions, return value notes, and possible exception information.
 
 (*) Understanding keyword tags is not part of the syllabus.
 
 The following keywords are part of the Standard Libraries of Robot Framework.
 Their documentation has been generated by the Robot Framework tool `libdoc` which is included in Robot Framework.
+In Robot Framework 7.5, the standard library documentation uses richer formatting and may contain more detailed structured descriptions than in older versions.
 
 ### 2.5.1.1 Example Keyword `Should Be Equal`
 
@@ -476,4 +478,3 @@ Should Be Equal    ${x}    expected    ignore_case=True    formatter=repr
 
 
 
-

website/docs/chapter-04/04_tags.md

@@ -12,10 +12,13 @@ Recall the purpose of Test|Task Tags in Robot Framework
 ::::
 
 In Robot Framework, **tags** offer a simple yet powerful mechanism for classifying and controlling the execution of tests|tasks.
-Tags are free-form text labels that can be assigned to tests|tasks to provide meta information, enable flexible test selection, and organize test results.
+Tags are free-form text labels that can be assigned to tests|tasks to group them, enable flexible test selection, and organize test results.
 
 Tags are also used to create a statistical summary of the test|task results in the execution protocols.
 
+If named descriptive information shall be stored for a test|task, such as an issue ID, an author, or a requirement reference, metadata is usually a better fit than tags.
+Tags are primarily intended for grouping, filtering, and reporting, while metadata stores explicit key-value information.
+
 **Important Note**: Tags are case-insensitive in Robot Framework, but the first appearance of a tag in a test|task is used as the tag name in reports and logs in its current case.
 
 
@@ -92,6 +95,7 @@ Tags can be used to select which tests|tasks are executed or skipped when runnin
 
 While tags are case-insensitive you should always use the lowercase version of the tag when filtering for tests|tasks with logical operators because logical operators are case-sensitive and uppercase.
 `AND`, `OR`, and `NOT` are the logical operators that can be used to combine tags in the filtering, but **they are not part of this syllabus!**
+In Robot Framework 7.5, deprecated compact forms like `XORY` and using `&` as a Boolean operator should not be used or taught.
 
 
 ### 4.4.2.1 Including Tests|Tasks by Tags
@@ -161,4 +165,3 @@ Using your own tags with this prefix may lead to unexpected behavior in test exe
 
 
 
-