github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-07-18 14:16:30 -05:00
Code Issues 16.9k Packages Projects Releases 122 Wiki Activity

[GH-ISSUE #7119] XML boot file for prompt and respond #4524

New Issue
Open
opened 2026-04-12 15:27:40 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-04-12 15:27:40 -05:00
Owner
Copy Link

Originally created by @julientype on GitHub (Oct 7, 2024).
Original GitHub issue: https://github.com/ollama/ollama/issues/7119

Boot XML file for classes to handle structured data and logic is a more robust and maintainable approach than using complex template syntax. Here’s why:

  1. Encapsulation of Logic:
    Class-based Approach: By encapsulating functionality within classes, you create a clear boundary around your logic. This leads to better organization and easier debugging.
    Templates: On the other hand, templates that rely heavily on conditionals can become tangled and difficult to manage as the project grows.
  2. Reusability:
    Classes: Classes can be reused across different parts of the application without rewriting logic. This promotes DRY (Don't Repeat Yourself) principles and allows for easier updates.
    Template Syntax: Modifying template logic can often require changes in multiple places, increasing the risk of introducing bugs.
  3. Readability and Maintainability:
    Class Definitions: Clear class definitions with well-named methods can enhance readability. Other developers can quickly grasp what a class does just by looking at its interface.
    Template Logic: Templated syntax, especially when it gets convoluted with conditions, can make it challenging for others (or even the original developer) to understand the flow of logic without extensive comments.
  4. Separation of Concerns:
    Class-based Systems: This promotes a separation of concerns, where data representation, logic, and presentation can be managed independently. For example, your ai.system class could handle loading, validating, and processing XML data without being intermingled with how that data is presented.
    Templates: This can lead to a conflation of data and presentation logic, which can complicate maintenance and testing.

The approach to using classes and structured XML is more aligned with software engineering best practices. It fosters a system that can evolve without the baggage of overly complex templates, making it easier for developers to work with and understand. If the goal is to develop a sustainable and maintainable AI system, sticking to solid OOP principles and clear data representations will always be the better choice.

Originally created by @julientype on GitHub (Oct 7, 2024). Original GitHub issue: https://github.com/ollama/ollama/issues/7119 Boot XML file for classes to handle structured data and logic is a more robust and maintainable approach than using complex template syntax. Here’s why: 1. Encapsulation of Logic: Class-based Approach: By encapsulating functionality within classes, you create a clear boundary around your logic. This leads to better organization and easier debugging. Templates: On the other hand, templates that rely heavily on conditionals can become tangled and difficult to manage as the project grows. 2. Reusability: Classes: Classes can be reused across different parts of the application without rewriting logic. This promotes DRY (Don't Repeat Yourself) principles and allows for easier updates. Template Syntax: Modifying template logic can often require changes in multiple places, increasing the risk of introducing bugs. 3. Readability and Maintainability: Class Definitions: Clear class definitions with well-named methods can enhance readability. Other developers can quickly grasp what a class does just by looking at its interface. Template Logic: Templated syntax, especially when it gets convoluted with conditions, can make it challenging for others (or even the original developer) to understand the flow of logic without extensive comments. 4. Separation of Concerns: Class-based Systems: This promotes a separation of concerns, where data representation, logic, and presentation can be managed independently. For example, your ai.system class could handle loading, validating, and processing XML data without being intermingled with how that data is presented. Templates: This can lead to a conflation of data and presentation logic, which can complicate maintenance and testing. The approach to using classes and structured XML is more aligned with software engineering best practices. It fosters a system that can evolve without the baggage of overly complex templates, making it easier for developers to work with and understand. If the goal is to develop a sustainable and maintainable AI system, sticking to solid OOP principles and clear data representations will always be the better choice.
GiteaMirror added the feature request label 2026-04-12 15:27:40 -05:00
GiteaMirror commented 2026-04-12 15:27:41 -05:00
Author
Owner
Copy Link

@julientype commented on GitHub (Oct 7, 2024):

Proposal: Enhancing Process Flow with a Basic Boot Loader

I propose developing a basic boot loader that serves as a gateway for interactive questioning, aimed at refining process flows and class constructor styles using Node.js. This simple project could provide a valuable environment for:

Iterative Improvement: By engaging in a dialogue to identify bottlenecks or inefficiencies, we can continuously enhance the workflow.
Flexible Design: The boot loader could allow for real-time adjustments to class constructors, enabling quick iterations based on user feedback.
Streamlined Development: This setup could serve as a privy project doorway, simplifying access to important components and ensuring that each element of the project can be easily addressed.
By implementing this system, we can foster a more agile development environment that encourages exploration and refinement of our methods.

Looking forward to your thoughts!

Best,
Julien

<!-- gh-comment-id:2397581965 --> @julientype commented on GitHub (Oct 7, 2024): Proposal: Enhancing Process Flow with a Basic Boot Loader I propose developing a basic boot loader that serves as a gateway for interactive questioning, aimed at refining process flows and class constructor styles using Node.js. This simple project could provide a valuable environment for: Iterative Improvement: By engaging in a dialogue to identify bottlenecks or inefficiencies, we can continuously enhance the workflow. Flexible Design: The boot loader could allow for real-time adjustments to class constructors, enabling quick iterations based on user feedback. Streamlined Development: This setup could serve as a privy project doorway, simplifying access to important components and ensuring that each element of the project can be easily addressed. By implementing this system, we can foster a more agile development environment that encourages exploration and refinement of our methods. Looking forward to your thoughts! Best, Julien
GiteaMirror commented 2026-04-12 15:27:41 -05:00
Author
Owner
Copy Link

@julientype commented on GitHub (Oct 7, 2024):

You don’t need an if statement to move orders around in this chain of commands between the AI Waiter and Chef. Each AI system (whether it's acting as a waiter or chef) can simply route the task to the next in line based on the type of request—without conditional logic like if.

BOOT XML -JSON-CDATA type:ai.system.data <<pointer to oop logic node tree array no if stagnation

BAD syntax looks like this.... are no if instructions in a waiter to chief class

where the {{ if .System }}
system_start: {{ .System }}
system_end:
{{ end }}

{{ if .Prompt }}
user_start: {{ .Prompt }}
user_end:
{{ end }}

<!-- gh-comment-id:2397597957 --> @julientype commented on GitHub (Oct 7, 2024): You don’t need an if statement to move orders around in this chain of commands between the AI Waiter and Chef. Each AI system (whether it's acting as a waiter or chef) can simply route the task to the next in line based on the type of request—without conditional logic like if. BOOT XML -JSON-CDATA type:ai.system.data <<pointer to oop logic node tree array no if stagnation BAD syntax looks like this.... are no if instructions in a waiter to chief class where the {{ if .System }} system_start: {{ .System }} system_end: {{ end }} {{ if .Prompt }} user_start: {{ .Prompt }} user_end: {{ end }}
GiteaMirror commented 2026-04-12 15:27:42 -05:00
Author
Owner
Copy Link

@julientype commented on GitHub (Oct 7, 2024):

Example Code with Conditionals (Trash Logic)def process_order(order):
if order['type'] == 'chicken':
if order['size'] == 'large':
if order['sauce'] == 'spicy':
return "Large Spicy Chicken"
else:
return "Large Mild Chicken"
elif order['size'] == 'small':
if order['sauce'] == 'spicy':
return "Small Spicy Chicken"
else:
return "Small Mild Chicken"
else:
return "Invalid size"
elif order['type'] == 'beef':
if order['size'] == 'large':
if order['sauce'] == 'bbq':
return "Large BBQ Beef"
else:
return "Large Plain Beef"
else:
return "Invalid size"
else:
return "Invalid order"

===Nested if/else statements: Each conditional checks for the order type, size, and sauce.
Multiple Paths: Every decision requires evaluating multiple conditions before returning the right response.
Maintenance issues: Adding new order types or conditions will make the logic even more complex, leading to more nested conditionals.

Optimized Version with Data-Driven Logic
Instead of using multiple if statements, we can store the options in a dictionary or use a lookup table, eliminating the need for nested conditionals.
def process_order(order):
# Predefined combinations
menu = {
('chicken', 'large', 'spicy'): "Large Spicy Chicken",
('chicken', 'large', 'mild'): "Large Mild Chicken",
('chicken', 'small', 'spicy'): "Small Spicy Chicken",
('chicken', 'small', 'mild'): "Small Mild Chicken",
('beef', 'large', 'bbq'): "Large BBQ Beef",
('beef', 'large', 'plain'): "Large Plain Beef"
}

# Get the order details
order_key = (order.get('type'), order.get('size'), order.get('sauce'))

# Return the result based on predefined options or give an error
return menu.get(order_key, "Invalid order")

======

Changes and Benefits:
No Nesting: We eliminated nested conditionals by using a data-driven approach.
Improved Readability: The logic is easier to understand, maintain, and extend. Just add more entries to the menu dictionary for new types, sizes, or sauces.
Efficient Execution: No more multiple if checks; everything is handled with a single lookup.
Scalability: If the options increase, you don’t need to write more conditionals. Simply update the dictionary.
Potential Changes in AI Logic
By replacing excessive if/else or branching logic in AI models:

We can reduce unnecessary evaluations.
Make the model more adaptive to dynamic data rather than fixed conditions.
Simplify debugging and improve performance in real-time operations.

<!-- gh-comment-id:2398046403 --> @julientype commented on GitHub (Oct 7, 2024): Example Code with Conditionals (Trash Logic)def process_order(order): if order['type'] == 'chicken': if order['size'] == 'large': if order['sauce'] == 'spicy': return "Large Spicy Chicken" else: return "Large Mild Chicken" elif order['size'] == 'small': if order['sauce'] == 'spicy': return "Small Spicy Chicken" else: return "Small Mild Chicken" else: return "Invalid size" elif order['type'] == 'beef': if order['size'] == 'large': if order['sauce'] == 'bbq': return "Large BBQ Beef" else: return "Large Plain Beef" else: return "Invalid size" else: return "Invalid order" ===Nested if/else statements: Each conditional checks for the order type, size, and sauce. Multiple Paths: Every decision requires evaluating multiple conditions before returning the right response. Maintenance issues: Adding new order types or conditions will make the logic even more complex, leading to more nested conditionals. ==== Optimized Version with Data-Driven Logic Instead of using multiple if statements, we can store the options in a dictionary or use a lookup table, eliminating the need for nested conditionals. def process_order(order): # Predefined combinations menu = { ('chicken', 'large', 'spicy'): "Large Spicy Chicken", ('chicken', 'large', 'mild'): "Large Mild Chicken", ('chicken', 'small', 'spicy'): "Small Spicy Chicken", ('chicken', 'small', 'mild'): "Small Mild Chicken", ('beef', 'large', 'bbq'): "Large BBQ Beef", ('beef', 'large', 'plain'): "Large Plain Beef" } # Get the order details order_key = (order.get('type'), order.get('size'), order.get('sauce')) # Return the result based on predefined options or give an error return menu.get(order_key, "Invalid order") ====== Changes and Benefits: No Nesting: We eliminated nested conditionals by using a data-driven approach. Improved Readability: The logic is easier to understand, maintain, and extend. Just add more entries to the menu dictionary for new types, sizes, or sauces. Efficient Execution: No more multiple if checks; everything is handled with a single lookup. Scalability: If the options increase, you don’t need to write more conditionals. Simply update the dictionary. Potential Changes in AI Logic By replacing excessive if/else or branching logic in AI models: We can reduce unnecessary evaluations. Make the model more adaptive to dynamic data rather than fixed conditions. Simplify debugging and improve performance in real-time operations.
GiteaMirror commented 2026-04-12 15:27:43 -05:00
Author
Owner
Copy Link

@julientype commented on GitHub (Oct 20, 2024):

Remember that CDATA objects in XML is read only if needed where JSON is read all
XML is the class application expert where JSON is the joint relation expert
like root Node has read all inner-text . I am innerText i am innerText
One call reads all and elements can be define as class ai.sytem.doc <<< a class

<!-- gh-comment-id:2425019085 --> @julientype commented on GitHub (Oct 20, 2024): Remember that CDATA objects in XML is read only if needed where JSON is read all XML is the class application expert where JSON is the joint relation expert like root Node has read all inner-text . <xml>I am innerText <doc><doc>i am innerText</doc></xml> One call reads all and elements can be define as class ai.sytem.doc <<< a class <ai><system><doc></doc></system></ai>
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label feature request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#4524
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?