The theory and practical way.
An HTTP response, a local file, and a string supplied by an application all enter CEM through the same import boundary. CEM-ML selects the parser for the input format, decodes the source, and builds a typed document tree. The shared importer supports XML and JSON alongside YAML, CSV, HTML, CSS, and formats such as SVG and MathML. Each format keeps its own semantics. A CSV field remains text until a query casts it, while XML elements retain their namespaces. CEM-QL, XPath, and templates use the same node interface across formats. CEM data import
Streaming starts with the bytes. CEM’s <http-request> loader reads the response body in chunks when the transport supports it. Request metadata can reach the template while the body is still arriving. Today, the loader collects the body within a configured byte limit, then imports and publishes the complete CEM document. The next stage in the design is to expose validated parser events as they arrive. A template could then render rows in source order, while an operation like sorting the entire result would still need to wait for the full input. Loader contract · Resource and AST stream lifecycle
Source maps keep the connection to the input. Imported nodes carry their source identity and ranges, so a query can return a decoded value while tooling can still locate the original text. For example, selecting a field from a CSV feed can preserve the location of that field in the response. The rendering design extends that trace in two directions, back to the data that supplied a displayed value and back to the template expression that placed it there. Imported-node provenance is available today. Full tracing from rendered DOM to response ranges is a design goal. Import provenance · Source maps for HTTP data
