The XMIR schema is used to validate the XMIR documents, which are generated by the EO parser. Every XMIR document is essentially an XML document that contains objects found in a EOLANG program together with supplementary information, such as metas, and so on. The schema is used to validate the XMIR documents, which are generated by the EO parser. The schema defines the structure of the XMIR document, including the elements and attributes that are allowed, their types, and any constraints that must be satisfied. By validating the XMIR documents against this schema, developers can ensure that the documents are well-formed and conform to the expected structure. This validation process helps maintain the integrity and consistency of the XMIR documents and ensures that they can be processed correctly by other tools or systems that consume them. Whole number Whole numbers, include zero. This type is used for line numbers, positions, etc. A non-empty string The value that is not empty (contains at least one character). This type is used for names, etc. Just empty string Empty string, to be used in attributes. A name of object attribute The name of an object attribute, which is used to reference the attribute from other objects or from the global scope. A fully qualified name of an object The fully qualified name of an object, which includes the names of all the objects that are its ancestors. This type is used to uniquely identify an object within the program. The FQN is typically used to reference objects from other objects or from the global scope, ensuring that the correct object is accessed or modified. A locator of an object The locator of an object, which specifies the location of the object within the program, in the global graph of objects, starting from Φ. The locator is used to uniquely identify an object within the program and is typically used to reference objects from other objects or from the global scope, ensuring that the correct object is accessed or modified. An object, as it is seen in the EO program The element contains all necessary details about a single object, including all its attributes (which are also objects). The object may also contain data, as text. The line of code where the object has been seen The attribute contains the number of code line (starting from 1), where the object has been met during the scanning of the source code. The position in the code line where the object has been seen The attribute contains the position in the code line (starting from 1), where the object has been met during the scanning of the source code. The name of the EO object inside its scope of visibility (another object or global) The attribute contains the name of the EO object inside its scope of visibility. The name is used to reference the object from other objects or from the global scope. The name of the object of which this one is a copy The attribute contains the name of the object of which this one is a copy. The base object is used to define the structure of the current object. The error found in the program The element explains what kind of problem is found in the program, where exactly, and what is the severity of it. The name of the checker that found the error The element contains the name of the style checker or any other submodule that found the error in the program. The number of the line of code where the error was found The element contains the number of the code line (starting from 1), where the error was found. If the element is omitted, the problem is related to the entire program, not to any particular line in it. The severity of the error The element contains the severity of the error, thus providing advice to the processor of the document on whether the error may be ignored (when it is a "warning") or the processing must stop immediately (when it is a "critical"). The comment found attached to an object Comments may be attached to objects in EO programs, but only to the highest-level formations. These comments provide additional context or explanations for the code, which can be useful for understanding the program's logic and intent. Comments are typically used to document the purpose of the code, describe complex logic, or provide other relevant information that can aid in code maintenance and readability. The entire listing of the source code program, in EO The `listing` element contains the entire listing of the source code program, in EO language, as it was seen by the scanner. This element does not have any structure and may be omitted. However, it is recommended to provide the listing to simplify debugging and enable traceability. By including the full source code listing, developers can easily reference the original code, which helps in understanding the context of the program and aids in troubleshooting any issues that may arise during the processing or execution of the program. The XSL stylesheet that was applied to the XMIR The element contains information about the XSL stylesheet that was applied to the XMIR during its optimization and/or transformation. This information is crucial for understanding the changes made to the XMIR document during these processes. The XSL stylesheet can include various transformations that optimize the structure, improve performance, or adapt the document for different purposes. By documenting the applied stylesheet, developers can trace back the modifications and ensure the integrity and correctness of the XMIR document. The meta found in the source code The element contains information about a meta found in the source code, before all objects. A "meta" in this context refers to metadata that provides additional information about the EO program. This metadata can include various details such as configuration settings, annotations, or other descriptive information that is not part of the main program logic but is essential for understanding, processing, or managing the program. Metas are typically used to convey information that can influence how the program is compiled, optimized, or executed. They can also be used for documentation purposes, to provide insights into the program's structure, dependencies, or other relevant attributes. The list of comments found in the source code The element may contain a collection of comments found in the source code attached to the highest-level EO formations. These comments provide additional context or explanations for the code, which can be useful for understanding the program's logic and intent. Comments are typically used to document the purpose of the code, describe complex logic, or provide other relevant information that can aid in code maintenance and readability. The list of errors already detected in the program The `errors` element may contain a collection of `error` elements that have already been identified in the program. These errors can be detected by the EO parser or any other additional analyzers, such as style checkers or linters. As the XMIR document undergoes various optimization or transformation pipelines, the list of errors may expand. It is up to the consumers of the XMIR document to decide whether to address these errors or to ignore them and continue processing. Each `error` element provides detailed information about the nature of the error, including its severity, the line of code where it was found, and the specific checker that identified it. This information is crucial for debugging and ensuring the quality of the EO program. The `errors` element is designed to help developers identify and resolve issues in their EO programs. By providing detailed information about each error, developers can quickly pinpoint the source of the problem and take appropriate action. The severity attribute indicates the importance of the error, allowing developers to prioritize their efforts. Critical errors may require immediate attention, while warnings can be addressed at a later time. Additionally, the `errors` element supports the continuous improvement of EO programs. As new analyzers and checkers are introduced, they can add their findings to the `errors` element, ensuring that all potential issues are documented in a single location. This centralized approach simplifies the debugging process and helps maintain the overall quality of the program. The list of XSL stylesheets that were applied to the XMIR The element may contain a collection of XSL stylesheets (their names) that were applied to the XMIR during its optimization or any other transformations. This element exists mostly for debugging purposes. The amount of milliseconds that were spent on creating this document The element contains a positive integer, which is the number of milliseconds that were spent by the parser to generate this document. This information is valuable for debugging purposes and may be omitted in production systems. The date and time when the document was created The element contains the date and time of the moment when the document was generated by the parser. This information is valuable for debugging purposes and may be omitted in production systems. The version of the parser that created the document The element contains the version of the parser that created the document, preferably in SemVer format. This information is valuable for debugging purposes and may be omitted in production systems. The Git SHA of the release of the parser that created the document The element contains the Git SHA of the release of the parser that created the document. This information is valuable for debugging purposes and may be omitted in production systems. The date-of-birth of the parser that created the document The element contains the date and time of the release of the parser that created the document. This information is valuable for debugging purposes and may be omitted in production systems.