luigidemasi opened a new issue, #107: URL: https://github.com/apache/camel-kit/issues/107
> Imported from [luigidemasi/camel-kit#247](https://github.com/luigidemasi/camel-kit/issues/247), opened by [Croway](https://github.com/Croway) on 2026-10-10. > Closed on 2026-10-14 without a linked pull request. --- ## Problem `skills/camel-migrate/guides/biztalk-pipeline-mapping.md` maps the default XMLReceive pipeline to schema validation: ``` | **XMLReceive** | Receive | `from(...).to("validator:schema.xsd")` | Validates XML, no disassembly. | ``` Both halves of the note are wrong for the default pipeline. Per Microsoft's [Default Pipelines](https://learn.microsoft.com/en-us/biztalk/core/default-pipelines) page, XMLReceive is Decode (empty), Disassemble (XML Disassembler), Validate (empty), ResolveParty (Party Resolution). And per [Document Validation in the XML Disassembler Pipeline Component](https://learn.microsoft.com/en-us/biztalk/core/document-validation-in-the-xml-disassembler-pipeline-component): "By default, the XML Disassembler does not validate XML documents against a schema. However, you can configure the XML Disassembler to validate an XML document by setting the **Validate Document Structure** property" (`ValidateDocument` in the binding's pipeline configuration, False by default). So a migrated route that adds `validator:` for an XMLReceive location changes behaviour: files BizTalk accepted are now rejected. The guide presents it as the equivalent instead of as a change to record. Same file, XML Disassembler section: it lists "Validates against schema (optional)" but the Camel equivalent below it always calls `validator:`, without saying this applies only when `ValidateDocument` is True. ## Evidence In an evaluation of coding agents (Claude Code and IBM Bob) migrating a small BizTalk solution (FILE receive location with the default XMLReceive pipeline, `ValidateDocument` not set), an LLM judge checking for invented behaviour failed at least 9 of 36 sessions for this one reason, across plain, camel-kit 0.4.1 and MCP setups. Typical finding: "MIGRATION.md justifies this by saying XMLReceive enforces the schema 'as the XMLReceive pipeline does', but the default XMLReceive pipeline does not validate documents, so this adds a validation behaviour the BizTalk solution does not have." None of those sessions opened `biztalk-pipeline-mapping.md`, so the guide did not cause the failures; the misconception comes from the model. But the guide currently states the same misconception, so an agent that does load it (Phase 2 requires it) is pushed toward the wrong mapping instead of away from it. Unchanged on `main`. ## Proposal 1. Replace the XMLReceive row: ``` | **XMLReceive** | Receive | XML Disassembler: parse; split only if an envelope schema is used | No schema validation unless the receive location sets `ValidateDocument=True` (with `DocumentSpecNames`). Do not add `validator:` by default. | ``` 2. Add under the default-pipelines table: > XMLReceive does not validate against the XSD unless the XML Disassembler's `ValidateDocument` (Validate Document > Structure) property is True in the receive location's pipeline configuration; it defaults to False. Check the > binding file. If it is not set, a `validator:` step is a behaviour change: add it only when the user asks for it, > and record it in the design spec and MIGRATION notes as an addition, not as preserved BizTalk behaviour. 3. In "XML Disassembler → split + unmarshal", mark the `validator:` step as conditional: "only if `ValidateDocument=True` in the source binding". Optionally, phase 1 could list `ValidateDocument` / `DocumentSpecNames` among the receive-location pipeline settings to capture, so phase 2 has the fact to hand. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
