CMSIS-Pack的组件与API：文件集合、接口规范和实现为何分开描述

Open-CMSIS-Pack的components页面开头，将component描述为Pack中的软件组件，并说它列出属于该组件、与项目有关的文件。这使“组件”与某一个文件有不同范围：文件在组件的清单中出现，组件还承担组织这些文件的身份。文档同时说明，组件本身或单个文件都可能关联condition；若条件在相应上下文中为false，所对应的组件或文件便不适用。条件落在哪一级，关系到说明针对整个集合还是其中一项。

组件的标识也不只是一段显示名称。每个组件必须有Cclass、Cgroup和Cversion，即类别、组及版本；Cbundle、Csub和Cvariant可再提供附加分类。供应者既可能从Pack取得，也可以由组件明确给出。原文用这些信息共同识别组件，因此只摘下一个group名，会删去同一条描述中的版本、供应者及其他分类背景。页面还明确，同一组件的多个variant互斥，不能把并列的变体名称读成可以同时属于一次选择。

Component Bundle进一步组织相互依赖、属于同一Cclass的组件。它是有名称的一组组件，成员共享Cvendor与Cclass，Cbundle成为组件标识的必要部分。Bundle里的Cvendor、Cclass、Cbundle及Cversion向内部组件继承，但只有Cversion能在内部重新定义。继承与可重新定义因此并非同一范围，文档没有让所有字段都能随内部组件任意改写。同一类别中属于不同bundle的组件，也被明确记为不可同时选择；这里采用的是文档的分组约束。

APIs页面则从接口规范出发。它将API称为C/C++接口规范，模块可通过实现或使用相应函数、数据类型及定义彼此配合，并明确接口规范可以与实际实现分开分发。CMSIS-RTOS是原文给出的例子：API属于CMSIS的规范内容，实际RTOS实现却由不同供应者提供。规范名称由此说明共同接口，而不能单凭这个名称认定背后只有一家实现供应者。

API自身也包含资料文件。文档列出名称、简短说明、一份或多份头文件，以及包含详细规范的文档，并提到可有include目录。Ethernet例子分别列MAC接口、PHY接口，以及同时定义两者的Ethernet接口，最后这一项有两个API头文件。这个例子使“一项API”与“一份头文件”不能直接画等号：接口作为具名规范出现，头文件则可有不同数量。

接口规范与组件文件在项目资料中的联系，由Cclass和Cgroup交代。API可以来自与组件相同的Pack，也可以来自另一个Pack；文档说，相关组件与API匹配这些类别时，项目涉及组件所列文件和API所列文件两组内容。因此，基于该API的组件不应再重复携带定义API的头文件。这里讨论的是两组文件的来源与分工，不是把API规范重新称为组件的全部实现。

/package/apis还被单独解释为分组容器：这一节可选，每个包中至多有一个；其内部具名的api条目却可以多次出现。容器的数量与内部条目的数量于是分属两级。把一个分组节简写成“这个包只能有一个API”，会遗漏文档允许多条接口规范的内部结构，也会混淆头文件数量与条目数量。

本篇采用主分支页面上可见的1.7.62文字，只解释微控制器开发生态中的资料对象与描述关系，不把main称为稳定发布版。没有转录配置或代码、构建执行，也不由格式约束给实际固件兼容结论；两页首次发表日期未确认。