YSFOML (Yasir Sultan File Operations Markup Language) Specification and Documentation, Version 1.0.6

Table of Contents

1. Introduction ↑ Top

YSFOML (Yasir Sultan File Operations Markup Language) is a powerful and intuitive markup language designed to streamline and automate file system operations. It provides a structured and human-readable way to define a series of file-related tasks, making complex operations simple and repeatable. YSFOML aims to bridge the gap between human intent and automated file management, offering a robust framework for various development and maintenance workflows.

One of the primary motivations behind the creation and continuous development of YSFOML is to empower programmers in their development process through the strategic use of Artificial Intelligence. YSFOML is meticulously designed to facilitate AI interaction with file systems, while simultaneously upholding the highest levels of security through its inherent 'human-in-the-loop' model. This crucial design choice ensures that AI models can leverage YSFOML for powerful automation without the risk of accessing sensitive data or executing malicious behaviors, thereby providing a secure and controlled environment for AI-driven development.

It is important to clarify that while the MCP protocol and YSFOML are distinct entities. please check section (YSFOML future aspects)

2. Core Concepts ↑ Top

2.1 YSFOML Block Structure ↑ Top

YSFOML operations are defined within <YSFOML> and </YSFOML> tags. Each block represents a single file system operation.

Syntax:

YSFOML
<YSFOML>
action: [action_name];
[parameter1]:[value1];
[parameter2]:[value2]
...
</YSFOML>
[Optional Content associated with the action]

2.2 Parameters ↑ Top

Parameters are key-value pairs within the YSFOML block that provide specific details for the action.

General Syntax: parameter_name:parameter_value;

2.3 Base Folder ↑ Top

All file system operations performed by the YSFOML parser are relative to a designated "base folder" (referred to as project_folder_name in the provided Python parser). If a file or folder path is specified without a leading slash (e.g., file1.txt, my_new_folder/nested_file.txt), it is assumed to be relative to this base folder.

2.4 Security Levels ↑ Top

YSFOML operations are categorized by security levels to indicate the potential impact on the file system. The YSFOML parser application may use these levels to enforce permissions or require higher user confirmation for more impactful operations.

2.5 User-Defined Actions (actionSource: userAdded) ↑ Top

While YSFOML provides a comprehensive set of built-in actions, future versions may allow for the definition of new, custom actions. If you are defining a new action that is not part of the standard YSFOML specification, you *must* include the actionSource: userAdded; parameter within the YSFOML block. This parameter signals to the parser that the action is a custom, user-defined one. Current YSFOML processors may log these actions as unsupported, but this mechanism is in place for future extensibility.

Example for a hypothetical user-added action:

YSFOML
<YSFOML>
action:myCustomAction;
actionSource:userAdded;
param1:value1;
param2:value2
</YSFOML>
This is content for my custom action.

2.6 YSFOML Document Visualization ↑ Top

<YSFOML>
action:create;
path:file1.txt;
</YSFOML>
This is the associated content for the new file. It can span multiple lines and is not a key:value pair.
<YSFOML>
action:create;
path:file2.txt;
</YSFOML>
This is the associated content for the new file.

Color Codes

YSFOML Document (Page Background)
YSFOML Article: #ffd8e6 (Pink)
YSFOML Block: #add8e6 (Light Blue)
Key-Value Pair: #e0f2f7 (Very Light Blue)
Key: #ffff99 (Light Yellow)
Value: #90ee90 (Light Green)
Associated Content: #ffcc99 (Light Orange)

3. Language Specification (Detailed Action Reference) ↑ Top

3.1 action:create ↑ Top

3.2 action:append ↑ Top

3.3 action:delete ↑ Top

3.4 action:createFolder ↑ Top

3.5 action:deleteFolder ↑ Top

3.6 action:rename ↑ Top

3.7 action:move ↑ Top

3.8 action:treeFolders ↑ Top

3.9 action:treeFiles ↑ Top

  • Purpose: Displays the full directory and file structure starting from a specified folder.
  • Parameters:
    • foldername: (Optional, String) The folder from which to start the tree display, relative to the base folder. If omitted, the base folder itself is used.
  • Security Level: low
  • Content: Not used.
  • Behavior:
    • Outputs the full file and folder tree to the "Operation Results" panel.
  • Example:
    YSFOML
    <YSFOML>
    action:treeFiles;
    foldername:
    </YSFOML>

3.10 action:findFile ↑ Top

  • Purpose: Searches for a specific file by name within a given folder and its subfolders.
  • Parameters:
    • filename: (Required, String) The name of the file to search for.
    • foldername: (Optional, String) The folder to start the search from, relative to the base folder. If omitted, the base folder itself is used.
  • Security Level: low
  • Content: Not used.
  • Behavior:
    • Outputs the full paths of all found instances of the file to the "Operation Results" panel.
  • Example:
    YSFOML
    <YSFOML>
    action:findFile;
    filename:renamed_file1.txt;
    foldername:
    </YSFOML>

3.11 action:findInFile ↑ Top

  • Purpose: Searches for occurrences of a specific string within a file.
  • Parameters:
    • filename: (Required, String) The path and name of the file to search within, relative to the base folder.
    • searchString: (Required, String) The string to search for.
  • Security Level: low
  • Content: Not used.
  • Behavior:
    • Outputs the line number and column number for each occurrence of the searchString to the "Operation Results" panel.
  • Example:
    YSFOML
    <YSFOML>
    action:findInFile;
    filename:daily_report.txt;
    searchString:sales
    </YSFOML>

3.12 action:replaceInFile ↑ Top

  • Purpose: Replaces all occurrences of a searchString with a newString within a specified file.
  • Parameters:
    • filename: (Required, String) The path and name of the file to modify, relative to the base folder.
    • searchString: (Required, String) The string to find and replace.
    • newString: (Required, String) The string to replace searchString with. Can be an empty string to delete occurrences.
  • Security Level: medium
  • Content: Not used.
  • Behavior:
    • A copy of the original file (with a timestamp) is created as a backup before modification.
    • If searchString is not found, no changes are made to the file, and a message is logged.
  • Example:
    YSFOML
    <YSFOML>
    action:replaceInFile;
    filename:daily_report.txt;
    searchString:$;
    newString:USD
    </YSFOML>

3.13 action:readFileAll ↑ Top

  • Purpose: Reads and displays the entire content of a specified file.
  • Parameters:
    • filename: (Required, String) The path and name of the file to read, relative to the base folder.
  • Security Level: low
  • Content: Not used.
  • Behavior:
    • Outputs the full content of the file to the "Operation Results" panel.
  • Example:
    YSFOML
    <YSFOML>
    action:readFileAll;
    filename:daily_report.txt
    </YSFOML>

3.14 action:readFileLines ↑ Top

  • Purpose: Reads and displays specific lines from a file.
  • Parameters:
    • filename: (Required, String) The path and name of the file to read, relative to the base folder.
    • startLine: (Optional, Integer) The starting line number (1-indexed). Defaults to 1.
    • endLine: (Optional, Integer) The ending line number (1-indexed). Defaults to the last line of the file if omitted or set to -1.
  • Security Level: low
  • Content: Not used.
  • Behavior:
    • Outputs the specified range of lines to the "Operation Results" panel, prefixed with their line numbers.
    • If startLine is out of bounds, an error is logged.
  • Example:
    YSFOML
    <YSFOML>
    action:readFileLines;
    filename:daily_report.txt;
    startLine:2;
    endLine:3
    </YSFOML>

3.15 action:insertAt ↑ Top

  • Purpose: Inserts text content at a specific line and column within a file.
  • Parameters:
    • filename: (Required, String) The path and name of the file to modify, relative to the base folder.
    • lineNum: (Required, Integer) The 1-indexed line number where the text should be inserted.
    • colNum: (Required, Integer) The 1-indexed column number within the specified line where the text should be inserted.
  • Security Level: medium
  • Content: The text content to insert into the file.
  • Behavior:
    • A copy of the original file (with a timestamp) is created as a backup before modification.
    • If lineNum is out of bounds, an error is logged.
    • If colNum is greater than the length of the line, the text is appended to the end of that line.
  • Example:
    YSFOML
    <YSFOML>
    action:insertAt;
    filename:daily_report.txt;
    lineNum:1;
    colNum:1
    </YSFOML>
    --- START OF REPORT ---

3.16 action:treeFoldersJSON ↑ Top

  • Purpose: Generates a machine-readable JSON representation of the directory structure (folders only) starting from a specified folder. This action is primarily intended for AI models to programmatically understand the project's folder layout.
  • Parameters:
    • foldername: (Optional, String) The folder from which to start the tree generation, relative to the base folder. If omitted, the base folder itself is used.
  • Security Level: low
  • Content: Not used.
  • Behavior:
    • Outputs a JSON object representing the folder tree to the "Operation Results" panel.
    • Each folder is represented with its name, type ("directory"), relative path, and a list of its contents (sub-folders).
    • Does not list individual files.
  • Example:
    YSFOML
    <YSFOML>
    action:treeFoldersJSON;
    foldername:my_new_folder
    </YSFOML>

3.17 action:treeFilesJSON ↑ Top

  • Purpose: Generates a machine-readable JSON representation of the full directory and file structure starting from a specified folder. This action is primarily intended for AI models to programmatically understand the complete project structure, including files.
  • Parameters:
    • foldername: (Optional, String) The folder from which to start the tree generation, relative to the base folder. If omitted, the base folder itself is used.
  • Security Level: low
  • Content: Not used.
  • Behavior:
    • Outputs a JSON object representing the full file and folder tree to the "Operation Results" panel.
    • Each item (folder or file) is represented with its name, type ("directory" or "file"), and relative path. Folders also include a list of their contents.
  • Example:
    YSFOML
    <YSFOML>
    action:treeFilesJSON;
    foldername:
    </YSFOML>

4. YSFOML future aspects ↑ Top

Looking to the future, a significant advancement planned for the YSFOML ecosystem involves the integration of the Multi-Client Protocol (MCP) directly within the YSFOML parser application. This strategic integration will largely eliminate the current need for manual copy-pasting of YSFOML code into the parser, although this option will remain available for flexibility. Instead, developers will be able to receive and review YSFOML code directly within a rich GUI environment, facilitating a more seamless and efficient workflow where their primary role shifts to critical review and approval.

It is important to clarify that while the MCP protocol and YSFOML are distinct entities--YSFOML defining file operations and MCP facilitating communication and interaction--their integration is designed to create a profoundly secure and exceptionally user-friendly development workspace. This synergy will combine YSFOML's precise control over file operations with MCP's robust communication capabilities, resulting in an environment where AI-driven file management is both powerful and inherently safe.

Further enhancing YSFOML's utility and flexibility, future iterations are planned to incorporate the crucial concepts of variables and conditional logic. These additions will enable more dynamic and intelligent file operation sequences, allowing YSFOML to adapt to varying contexts and execute operations based on specific criteria.

To address the critical need for running scripts and compiling code in a strict secured way, YSFOML will introduce new actions and security protocols designed to integrate these powerful capabilities without compromising the system's integrity. This will involve:

  • Dedicated Actions for Execution and Compilation: New YSFOML actions, such as executeScript and compileCode, will be introduced. These actions will be classified under the extremelyHigh security level, mandating explicit human review and approval via the rich GUI provided by the MCP integration. Parameters for these actions will include the script/source file path, interpreter/compiler executable, arguments, and options for capturing output (stdout/stderr).
  • Enhanced Human-in-the-Loop Review: The MCP-integrated GUI will provide a highly detailed and prominent display for any YSFOML block containing executeScript or compileCode actions. This display will highlight the exact command to be executed, its parameters, and any potential security implications, ensuring the human operator has all necessary information for a fully informed approval or rejection.
  • Whitelisting and Sandboxing Mechanisms: To mitigate risks, the YSFOML parser will support configurable whitelisting of approved script interpreters (e.g., specific Python versions, specific shell paths) and compilers. For even greater security, future considerations include sandboxing capabilities, where scripts and compilation processes are executed within isolated environments with limited access to the file system and network, further containing any potential malicious activity.
  • Output Capture and Analysis: The output (both standard output and error output) of executed scripts and compilation processes will be captured by the YSFOML parser and presented to the human reviewer within the GUI. This allows for immediate verification of the operation's success or failure, and crucially, enables the human to identify any unexpected behavior or errors before proceeding with subsequent YSFOML operations.
  • Integration with Variables and Conditional Logic for Safety: The introduction of variables and conditional logic will be instrumental in building robust security checks around script execution and compilation. For instance, a YSFOML sequence could first use findFile or readFileAll to verify the content or digital signature of a script before executeScript is allowed to proceed, or compileCode could be conditional on the successful outcome of a prior security scan. This allows for highly sophisticated, self-regulating security protocols defined directly within YSFOML.
  • Comprehensive Logging and Audit Trails: Every instance of script execution or code compilation, along with the human approval status and captured output, will be meticulously logged. This provides an immutable audit trail, critical for security compliance, debugging, and post-incident analysis.

By meticulously designing these new capabilities with security as the paramount concern, YSFOML will empower AI models to automate complex development tasks, including building and testing, while maintaining the essential human oversight that guarantees safety and control.

5. YSFOML and Artificial Intelligence ↑ Top

YSFOML is designed with Artificial Intelligence (AI) interaction in mind, serving as a structured and human-readable language for AI models to specify file system operations. This allows AI to communicate desired file manipulations in a clear, auditable format.

A core principle of YSFOML's design, especially when used with AI, is the "human-in-the-loop" security model. AI models can generate YSFOML instructions based on user requests (e.g., "Please create a Python script and save it as 'hello.py'"). However, the execution of these instructions is intentionally manual: the AI provides the YSFOML text, and the user must then copy and paste this text into the YSFOML Parser application. This manual step acts as a critical security layer, preventing direct, unsupervised AI access to your local file system.

By generating YSFOML instructions, AI can help users understand, create, and edit code, manage project files, or perform other file-related tasks. This approach empowers users with AI assistance while maintaining ultimate control and oversight over their file system.

It is crucial to understand that the execution of any YSFOML instructions, whether generated by an AI or written manually, is entirely at the user's own risk. Users are strongly advised to always review the generated YSFOML content carefully before processing it with the YSFOML Parser, especially for actions with medium or high security levels that can modify or delete files.

5.1 AI Workflow for Project Understanding and Modification ↑ Top

For an AI to effectively assist with file system operations, especially in complex projects, it's essential for the AI to first gain an understanding of the project's structure and existing content. The action:treeFoldersJSON and action:treeFilesJSON actions are specifically designed for this purpose.

  • Initial Project Overview: An AI should begin by requesting a JSON representation of the project's folder or file tree using action:treeFoldersJSON (for a high-level folder structure) or action:treeFilesJSON (for a detailed view including all files). This provides the AI with a structured, machine-readable map of the project.
  • Content Analysis: Once the AI has the project structure, it can then identify relevant files (e.g., source code, configuration files, data files). For specific files, the AI can then use action:readFileAll or action:readFileLines to read their content and understand their purpose or identify areas for modification.
  • Generating Modification Instructions: With a clear understanding of the project structure and file contents, the AI can then generate precise YSFOML instructions for operations like action:create, action:append, action:replaceInFile, or action:insertAt to make the desired changes. This iterative process of "read-then-write" ensures that AI-generated modifications are contextually aware and accurate.

This structured approach allows the AI to provide more intelligent and targeted assistance, while the human-in-the-loop model ensures safety and oversight.

5.2 Key AI Interaction Capabilities ↑ Top

YSFOML offers several powerful and secure ways for Artificial Intelligence (AI) to interact with file systems:

  • AI-Driven File Generation and Creation: AI can generate YSFOML instructions to create new files, such as source code, configuration files, or documentation, based on user requirements.
  • AI-Assisted File Modification: AI can generate YSFOML to perform operations that modify existing files, including appending content, inserting content at specific locations, or replacing text within files. This allows AI to "edit" files in a structured and auditable manner.
  • AI-Powered Project Structure Understanding: YSFOML provides specific actions that allow AI models to programmatically obtain a machine-readable JSON representation of a project's directory and file structure. This is crucial for AI to gain context and understand the layout of a project before suggesting or performing operations.
  • AI-Guided File System Querying and Analysis: AI can use YSFOML's read-only operations to analyze file content and structure. This includes searching for specific files, finding strings within files, or reading entire file contents or specific lines. This enables AI to perform detailed analysis and retrieve necessary information from the file system.
  • Human-in-the-Loop Automation and Security: A core principle highlighted is the "human-in-the-loop" security model. While AI can generate complex YSFOML instructions, the execution is intentionally manual. The user reviews the AI-generated YSFOML before processing it with the YSFOML Parser. This ensures that users maintain ultimate control and oversight over their local file system, especially for operations with medium or high security levels that can modify or delete files.

In summary, YSFOML serves as a structured, human-readable interface that allows AI to understand, query, and propose modifications to file systems, while ensuring a critical human review step for security and control.

5.3 Examples of YSFOML Instructions for AI Usage Scenarios ↑ Top

1. AI-Driven File Generation and Creation

An AI is asked to create a new Python script for a simple "Hello World" program.

YSFOML
<YSFOML>
action:create;
filename:hello_world.py
</YSFOML>
print("Hello, YSFOML World!")

2. AI-Assisted File Modification

Scenario A: Appending content to an existing file.

An AI needs to add a new log entry to an existing application.log file.

YSFOML
<YSFOML>
action:append;
filename:application.log
</YSFOML>
[2025-06-28 15:30:00] INFO: User 'admin' logged in successfully.
Scenario B: Replacing content within a file.

An AI identifies a placeholder in a configuration file and needs to replace it with an actual value.

YSFOML
<YSFOML>
action:replaceInFile;
filename:config.ini;
searchString:DB_PASSWORD=YOUR_PASSWORD;
newString:DB_PASSWORD=secure_ai_pass123;
</YSFOML>
Scenario C: Inserting content at a specific position in a file.

An AI needs to add a new function definition at the beginning of a Python script.

YSFOML
<YSFOML>
action:insertAt;
filename:my_utility.py;
lineNum:1;
colNum:1
</YSFOML>
def calculate_sum(a, b):
    return a + b

3. AI-Powered Project Structure Understanding

Scenario A: Getting a JSON representation of folder structure.

An AI needs a high-level overview of the project's directories to understand its organization.

YSFOML
<YSFOML>
action:treeFoldersJSON;
foldername:src/components;
</YSFOML>
Scenario B: Getting a JSON representation of the full file and folder structure.

An AI needs a detailed map of all files and folders within a specific directory to plan modifications.

YSFOML
<YSFOML>
action:treeFilesJSON;
foldername:public/assets;
</YSFOML>

4. AI-Guided File System Querying and Analysis

Scenario A: Reading the entire content of a file.

An AI needs to analyze the content of a specific source code file.

YSFOML
<YSFOML>
action:readFileAll;
filename:src/main.js
</YSFOML>
Scenario B: Searching for a string within a file.

An AI is looking for all occurrences of a specific variable name (user_id) in a database script.

YSFOML
<YSFOML>
action:findInFile;
filename:database/schema.sql;
searchString:user_id;
</YSFOML>
Scenario C: Searching for a specific file.

An AI needs to locate all instances of config.json across the project.

YSFOML
<YSFOML>
action:findFile;
filename:config.json;
foldername:;
</YSFOML>

5. Human-in-the-Loop Automation and Security

This scenario is represented by the overall workflow and the use of security levels. An AI would generate one of the YSFOML blocks, and a human user would then review it before feeding it into the YSFOML Parser application. For instance, a deleteFolder instruction has a high security level, requiring careful human review.

YSFOML
<YSFOML>
action:deleteFolder;
foldername:old_backup_data;
</YSFOML>

6. AI Chat Examples ↑ Top

Chat 1

User:

i want to create a website with a key to switch between dark mode and light mode make all file (HTML + CSS + JS) use YSFOML from https://github.com/professor-YasirSultan/YSFOML create a single YSFOML document to create all this file

AI:
YSFOML
<YSFOML>
action:create;
filename:index.html
</YSFOML>
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Dark/Light Mode Toggle</title>
    <link rel="stylesheet" href="style.css">
</head>
<body class="light-mode">
    <div class="container">
        <h1>Welcome to My Website</h1>
        <p>This is a simple example demonstrating dark and light mode toggling.</p>
        <button id="modeToggle">Toggle Mode</button>
    </div>
    <script src="script.js"></script>
</body>
</html>
<YSFOML>
action:create;
filename:style.css
</YSFOML>
body {
    font-family: Arial, sans-serif;
    margin: 0;
    display: flex;
    justify-content: center;
    align-items: center;
    min-height: 100vh;
    transition: background-color 0.3s, color 0.3s;
}

/* Light Mode Styles */
body.light-mode {
    background-color: #f0f0f0;
    color: #333;
}

/* Dark Mode Styles */
body.dark-mode {
    background-color: #333;
    color: #f0f0f0;
}

.container {
    text-align: center;
    padding: 20px;
    border-radius: 8px;
    box-shadow: 0 4px 8px rgba(0, 0, 0, 0.1);
    background-color: #fff; /* White background for container in light mode */
    transition: background-color 0.3s, box-shadow 0.3s;
}

body.dark-mode .container {
    background-color: #555; /* Darker background for container in dark mode */
    box-shadow: 0 4px 8px rgba(0, 0, 0, 0.5);
}

h1 {
    margin-bottom: 15px;
}

p {
    margin-bottom: 25px;
}

button {
    padding: 10px 20px;
    font-size: 16px;
    border: none;
    border-radius: 5px;
    cursor: pointer;
    transition: background-color 0.3s, color 0.3s;
}

body.light-mode button {
    background-color: #007bff;
    color: white;
}

body.light-mode button:hover {
    background-color: #0056b3;
}

body.dark-mode button {
    background-color: #28a745;
    color: white;
}

body.dark-mode button:hover {
    background-color: #218838;
}
<YSFOML>
action:create;
filename:script.js
</YSFOML>
document.addEventListener('DOMContentLoaded', () => {
    const modeToggle = document.getElementById('modeToggle');
    const body = document.body;

    // Check for saved theme preference
    const savedTheme = localStorage.getItem('theme');
    if (savedTheme) {
        body.className = savedTheme;
    } else {
        // Default to light mode if no preference is saved
        body.className = 'light-mode';
    }

    modeToggle.addEventListener('click', () => {
        if (body.classList.contains('light-mode')) {
            body.classList.remove('light-mode');
            body.classList.add('dark-mode');
            localStorage.setItem('theme', 'dark-mode');
        } else {
            body.classList.remove('dark-mode');
            body.classList.add('light-mode');
            localStorage.setItem('theme', 'light-mode');
        }
    });
});
User:

give me YSFOML code to make sure all files are made correctly (just make sure of files tree)

AI:
YSFOML
<YSFOML>
action:treeFiles;
foldername:
</YSFOML>
User:
--- File Tree for '' ---
website2/
    index.html
    script.js
    style.css
    logs/
        input_2025-06-28_11-51-39.txt
        input_2025-06-28_18-12-21.txt
        processing_log_2025-06-28_11-51-39.txt
        results_log_2025-06-28_11-51-39.txt
--- End File Tree ---
AI:

This output confirms that index.html, script.js, and style.css were successfully created directly within the website2/ folder, as intended. The logs/ subdirectory and its contents are also present, which is normal for the YSFOML parser.

So, yes, the files were made correctly according to the file tree.

Chat 2

User:

i'm experienced developer, but i'm new to laravel. and i have laravel project that i need to develop. i want to know all MVC and routes files/classes in the project. give me YSFOML code that list only MVC and routes files/classes. YSFOML are specifications are here: https://github.com/professor-YasirSultan/YSFOML

AI:
YSFOML
<YSFOML>
action:treeFilesJSON;
foldername:app/Models;
</YSFOML>

<YSFOML>
action:treeFilesJSON;
foldername:app/Http/Controllers;
</YSFOML>

<YSFOML>
action:treeFilesJSON;
foldername:resources/views;
</YSFOML>

<YSFOML>
action:treeFilesJSON;
foldername:routes;
</YSFOML>
User:

// user send the result

AI:

Here's an explanation of each section .....

User:

i want you to explain the content of YSController.php (you may use YSFOML codes)

AI:

Explanation of YSController.php ....

7. Using the YSFOML Parser Application ↑ Top

The provided Python script YSFOML_GUI acts as a parser and executor for YSFOML documents.

7.1 Requirements ↑ Top

  • Python 3.x
  • tkinter (usually included with Python)
  • requests library (pip install requests)
  • For action:json with jsonPath, a JSONPath library might be required (e.g., pip install jsonpath-ng).

7.2 Running the Application ↑ Top

  1. Save the provided Python code as a .py file (e.g., ysfoml_parser.py).
  2. Run it from your terminal: python ysfoml_parser.py

7.3 Application Interface ↑ Top

The GUI provides the following main components:

  • YSFOML Input: A text area where you paste or type your YSFOML document.
  • Project Folder: An entry field and a "Browse" button to select the base directory where all file operations will be performed. By default, it creates an YSFOML_output folder in the current working directory.
  • Process YSFOML Button: Initiates the parsing and execution of the YSFOML content.
  • Processing Logs: Displays detailed logs of each step, including warnings, errors, and success messages for file operations.
  • Operation Results: Displays the output of query-based operations like treeFolders, findFile, readFileAll, etc.
  • Security Level Dropdown: Allows the user to select a security level (low, medium, high, extremelyHigh) that will restrict which YSFOML actions can be executed.

7.4 Workflow ↑ Top

  1. Prepare YSFOML: Write or paste your YSFOML instructions into the "YSFOML Input" text area.
  2. Select Base Folder: Choose or confirm the "Project Folder" where the operations will take place.
  3. Select Security Level: Choose the appropriate security level from the dropdown. Operations requiring a higher security level than selected will be blocked.
  4. Process: Click "Process YSFOML".
  5. Review Output: Check the "Processing Logs" for the status of each operation and the "Operation Results" for the output of query actions.
  6. Check File System: Verify the changes in your chosen "Project Folder".

7.5 Logging ↑ Top

The parser automatically saves three log files for each processing run within a logs subfolder inside your chosen project folder:

  • input_[timestamp].txt: A copy of the YSFOML content that was processed.
  • processing_log_[timestamp].txt: The full content of the "Processing Logs" panel.
  • results_log_[timestamp].txt: The full content of the "Operation Results" panel.

9. Error Handling and Best Practices ↑ Top

11.1 Error Handling ↑ Top

  • The parser attempts to log descriptive error messages to the "Processing Logs" panel for failed operations (e.g., file not found, permission errors, invalid parameters).
  • Syntax errors within the key:value; pairs might lead to parameters not being correctly parsed, resulting in "Warning: No 'key' found" messages.
  • Missing closing </YSFOML> tags will result in warnings and incomplete parsing.
  • For critical errors (e.g., missing Python libraries), a tkinter.messagebox will appear.
  • Operations that fail due to insufficient security levels will be logged and prevented from executing.

11.2 Backup Mechanism ↑ Top

  • For create, append, replaceInFile, and action:json (write mode) operations, the parser creates a timestamped backup of the original file before modification. This is a crucial safety feature to prevent accidental data loss. Backups are stored in the same directory as the original file.

11.3 Best Practices ↑ Top

  • Test on Dummy Data: Always test your YSFOML scripts on a non-critical "Project Folder" or with dummy files first, especially for destructive operations like delete or deleteFolder.
  • Clear Paths: Use clear and consistent relative paths for filenames and foldernames.
  • Review Logs: Always review the "Processing Logs" after execution to ensure all operations completed as expected and to identify any warnings or errors.
  • One Action Per Block: Adhere to the "one action per YSFOML block" principle for clarity and proper parsing.
  • Semicolons: Remember to end each parameter definition with a semicolon.
  • Content Placement: Ensure the content associated with an action immediately follows its </YSFOML> tag.

12. Limitations ↑ Top

  • No Conditional Logic: YSFOML currently does not support conditional statements (if/else) or loops. Operations are executed sequentially as they appear in the document.
  • No Variables: There is no support for defining and using variables within YSFOML.
  • No External Scripting: YSFOML cannot directly execute external scripts or commands.
  • Single File Processing: The parser processes the entire input as a single YSFOML document.
  • Platform Dependent Paths: While os.path.join is used for path construction, complex path manipulations or platform-specific characters might behave unexpectedly.
  • No Undo Feature: Operations are permanent on the file system (except for the automatic backups for certain actions). There is no built-in "undo" functionality for the sequence of operations.

13. Disclaimer ↑ Top

YSFOML (Yasir Sultan File Operations Markup Language) and the YSFOML Processor application are currently under development. They are provided "as is" without warranty of any kind, either express or implied. Use at your own risk. The developer is not responsible for any data loss or other damages incurred from the use of this software.