FieldML 是专为生物医学多物理场建模设计的声明式XML元语言，核心是无歧义描述定义在空间/时间域上的数学场（如心肌电位、应力分布），通过domain、field、basis等原子构件组合表达场的定义、依赖与运算关系，而非存储原始数据。
FieldML 是一种专为计算建模领域（尤其是生物医学与生理系统建模）设计的 XML 元语言（meta-language），不是通用数据交换格式，也不是像 DICOM 或 HL7 那样的临床信息标准；它核心解决的是：如何无歧义、可复用、可扩展地描述“场”（field）——即定义在空间、时间或参数域上的数学函数或映射关系。
这在心脏电生理、组织力学、血流动力学等多物理场耦合模拟中极为关键：比如“心肌细胞跨膜电位随空间位置和时间变化的函数”，或“某时刻应力张量在三维解剖网格上的分布”。
FieldML 本质是“场的声明式蓝图”，不是数据容器
你不会用它直接存一组 1024×768 的图像像素值，也不会拿它当数据库导出 XML。它的作用更接近：用 XML 写清楚“这个场怎么算出来的”——包括定义域（domain）、基函数（basis）、参数绑定、嵌套表达式（如 f(x,t) = g(h(x)) + ∂u/∂t）。
- 它把“形状”（几何/拓扑结构）和“函数”（数值行为）彻底分离，避免传统格式（如 Exodus II）中“四面体单元+线性插值”这种硬编码耦合
- 所有字段（
field）必须关联一个domain（可以是连续流形，如三维空间；也可以是离散点集，如电极位置） - 基础构件极少：只有
domain、field、basis、parameter、operation等几个核心元素，靠组合表达复杂性
为什么医学模拟需要 FieldML，而不是直接用 CellML 或 HDF5？
CellML 擅长描述**常微分方程组（ODE）和生物化学反应动力学**，比如离子通道门控变量演化；而 FieldML 处理的是**定义在几何域上的场变量及其空间依赖关系**——二者常配合使用（CellML 描述节点行为，FieldML 描述节点如何分布在解剖结构上）。
-
HDF5存得下海量场数据，但不存“这个场是怎么从另一个场导出的”，也不存“该场在边界上满足什么约束” -
Exodus II支持网格+结果，但固定了单元类型和插值阶数，无法表达非局部算子（如积分核、图像卷积场）、时间嵌套映射或参数化形变 - FieldML 的
operation可以声明derivative、integral、embedding、composition，这是构建真实生理模型推导链的基础
常见错误现象：
- 把 FieldML 当成“带注释的 HDF5”来用 → 导致元信息缺失，后续工具无法自动重建场依赖图
- 在
field中直接塞二进制数据块 → 违反其“描述性”定位，失去可读性与可验证性
实际工程中怎么用？注意三个落地卡点
FieldML 目前仍属小众标准，主要集成在 OpenCMISS、cmgui 和部分 Physiome 项目（如 euHeart）中。没有主流编程语言的原生解析库，需依赖 C++/Python 绑定或 XSLT 转换。
-
不要手写完整 FieldML：它语法严谨（XML Schema 验证严格），建议用
OpenCMISS-iron或FieldML Python bindings自动生成，再人工调整语义标签（如metadata中的physiological_unit） -
域（
domain）必须显式声明维度与拓扑：例如domain dimension="3" manifold="true"和domain dimension="1" manifold="false"（离散电极序列）语义完全不同，混用会导致求解器报错“domain mismatch” -
避免在
field中滥用 XPath 引用：FieldML 不是通用 XML 查询语言；xpath属性仅用于key/unique约束（见 W3C XML Schema 规范），不能用来动态取值——那是运行时逻辑，应由宿主程序（如 OpenCMISS）处理
FieldML 的真正门槛不在语法，而在建模思维：它强制你把“一个物理量怎么定义、在哪定义、怎么计算”拆解成可组合、可验证的原子单元。医学模拟越逼近真实器官的多尺度、多物理特性，就越绕不开这套表达——只是目前多数团队仍停留在“先跑通仿真，再补元数据”的阶段，而 FieldML 要求你从第一行就决定好场的数学身份。
