Nested Element Depth Control Prompt Template

This prompt is for developers and integration engineers who need to generate complex, hierarchical XML documents where the nesting depth must not exceed a specific limit. The primary job-to-be-done is preventing parser crashes, schema validation failures, or downstream processing errors in systems that have hard limits on element depth, such as certain XML parsers, XSLT processors, or legacy enterprise service buses. The ideal user is someone building a data pipeline, a configuration generator, or a document assembly system where the AI model is producing XML that must be immediately machine-consumable without manual cleanup.

You should use this prompt when the target XML schema or processing environment has a documented maximum depth constraint, and you need the model to actively count and control nesting levels during generation. It is also appropriate when you are generating XML from deeply nested source data, such as converting a multi-level JSON object or a complex domain model into XML, and you need the model to flatten or restructure the output to stay within bounds. The prompt includes explicit depth-counting instructions and fallback strategies, making it suitable for production pipelines where structural validity is a hard requirement.

Do not use this prompt when depth control is not a strict requirement, or when the target system can handle arbitrary nesting. In those cases, a simpler XML generation prompt will be more token-efficient and less prone to over-refactoring the document structure. Also, avoid this prompt if your primary goal is to enforce a specific schema (use the XSD-Compliant Document Generation Prompt Template instead) or to handle mixed content with CDATA sections (use the CDATA Section Handling Prompt Template). For high-stakes environments like healthcare FHIR XML or SAML assertions, always pair this prompt with human review and automated schema validation, as depth flattening can inadvertently alter the semantic meaning of the document if not carefully reviewed.

This prompt template is designed to generate a valid XML document from a structural description while strictly enforcing a maximum nesting depth. It is intended for developers who must produce XML that downstream parsers, schema validators, or legacy systems can handle without stack overflow or complexity errors. The template uses square-bracket placeholders for all dynamic inputs, making it easy to wire into an application harness where variables are resolved before the model call.

textCopy
You are an XML generation engine that produces valid, well-formed XML documents.

Your task is to generate an XML document based on the structural description provided in [STRUCTURE_DESCRIPTION].

# Constraints
- The maximum nesting depth of any element from the root is [MAX_DEPTH]. Count the root element as depth 1.
- If the described structure would naturally exceed [MAX_DEPTH], you MUST flatten the hierarchy. Use one of the following strategies:
  - Convert nested child elements into attributes of the parent element where semantically appropriate.
  - Represent deeply nested relationships as a flat list of sibling elements with `ref` or `id`/`idref` attribute pairs to maintain the logical connection.
  - Break the structure into multiple valid XML fragments, each within the depth limit, and wrap them in a root container if [ALLOW_FRAGMENTS] is true.
- Do not use CDATA sections to hide depth. The element nesting itself must stay within the limit.
- All XML must be well-formed: properly closed tags, correct attribute quoting, and a single root element (unless fragments are explicitly allowed).
- Use the namespace [NAMESPACE] for all elements if provided. If [NAMESPACE] is empty, omit namespace declarations.

# Output Format
Return ONLY the raw XML document. Do not include any explanatory text, markdown fences, or code block delimiters before or after the XML.

# Structure Description
[STRUCTURE_DESCRIPTION]

# Examples
[EXAMPLES]

To adapt this template, replace each square-bracket placeholder with concrete values before sending it to the model. [STRUCTURE_DESCRIPTION] should contain a natural language or structured description of the desired XML hierarchy. [MAX_DEPTH] must be an integer (e.g., 5). [ALLOW_FRAGMENTS] should be set to true or false to control whether multi-fragment output is acceptable. [NAMESPACE] should be a full namespace URI or an empty string. The [EXAMPLES] placeholder is critical for few-shot learning; provide at least one example showing a structure that exceeds the depth limit and its correctly flattened output. After generation, always validate the output with an XML parser and a depth-counting function before passing it to any downstream system.

Integrating this prompt into an application requires treating depth control as a hard constraint, not a suggestion. The prompt template accepts a [MAX_DEPTH] parameter and a [FLATTENING_STRATEGY] instruction, but the application layer must enforce these independently. Before calling the model, compute the expected depth budget from your target schema or parser limits (e.g., a downstream SAX parser may enforce a maximum of 50 nested elements). Pass this value explicitly into the prompt. After receiving the model output, run a depth-counting validator that traverses the XML tree and flags any element exceeding the limit. Do not rely on the model's self-reported depth count—always measure it programmatically.

The implementation loop should follow a validate-repair-escalate pattern. First, parse the model output with a non-validating XML parser to confirm well-formedness. Second, run the depth validator: a recursive function that tracks the current depth and records the XPath of any element exceeding [MAX_DEPTH]. If violations are found, construct a retry prompt that includes the original input, the depth limit, the specific violating paths, and an instruction to flatten those paths using the chosen strategy (e.g., convert deep nesting to attribute-based references or sibling elements with ref IDs). Retry once. If the retry still violates depth constraints, apply a programmatic flattening transform as a safety net—this is your circuit breaker. Log every violation and retry attempt with the model ID, prompt version, depth limit, and violating paths for observability.

Model choice matters here. Models with strong XML generation capabilities (like Claude 3.5 Sonnet or GPT-4o) handle depth constraints more reliably than smaller models, but no model is immune to nesting drift in long documents. For high-stakes integrations—such as generating XML for financial regulatory filings or healthcare FHIR resources—always include a human review gate when the programmatic flattening fallback is triggered. The review interface should highlight the flattened elements and show the original deep structure side by side. For batch processing, consider setting a stricter depth limit than the parser's absolute maximum to leave headroom for unexpected nesting from upstream data. Wire the depth validator into your CI/CD eval suite with a golden test set that includes intentionally deep input structures to catch regression in model behavior across prompt or model version updates.