Microsoft将产品配置模型用于表达一种通用产品结构，component是其中的主要构件，并以树结构组织。subcomponent引用已经存在的component，使同一构件可以被多个产品配置模型复用。[1]
属性描述模型的特征，加入模型的attribute会引用相应attribute type。文档把mandatory、read-only和hidden分别定义：mandatory在配置产品时必须有值，read-only显示值但不允许在该会话改变，hidden仍进入约束和条件却不显示。[1]
属性与条件还有两项更具体的关系。原文说，为属性指定条件后，条件满足时mandatory属性必须有值；同时，任何被条件引用的属性都会成为mandatory。这把是否需要一项值，与条件用到了哪些属性相接。在资料说明中，必填不只是一枚脱离上下文的标签，还要保留原文点名的条件成立和引用关系；本篇没有写出或执行条件表达式。[1]
attribute types规定属性的数据类型。总列表有带或不带范围的整数、小数、带或不带固定列表的文本，以及布尔类型。solver识别的范围却更窄，只包括布尔、有范围整数和固定列表文本，因此只有这几类能用于所述expression constraints和conditions。[1]
expression constraint与某个component相联系，只能用于其所绑定的构件，但可以引用该构件的subcomponent属性。这给约束本身的适用位置和它所引用的属性留下两份联系：约束仍属于特定构件，所读属性却可以在它的下级。[1]
用户定义的table constraint则是一张描述属性值组合的矩阵。文档用扬声器表面finish和前格栅作纸面例：Black表面对应Black、Metal和White三种格栅；Oak只列Black，Rosewood只列White，White表面列Black和White。四种表面与三种格栅虽各自列出，表内保留的却是具体配对，并非将两份列表任意两两组合。[1]
系统定义的table constraint采用另一种来源关系：它把attribute type动态联系到Supply Chain Management表中的字段，让模型属性反映该字段的数据。上一段的用户矩阵直接列出允许组合，这里的系统表约束则保留对既有表字段的映射。两者同属table constraint，资料从哪里来仍在定义中分别说明。[1]
calculation被称作对约束的补充。文档将小数和整数属性的算术运算，与固定列表文本、布尔属性的逻辑运算分别点名，并为结果设置target attribute。因而，一个计算对象不仅有关联的输入属性，还明确有承接结果的属性。[1]
user requirement又处在用户需要和具体component、attribute之间的抽象层，不能直接映射到item。与此相邻，隐藏subcomponent会使相关的attributes、subcomponents及user requirements也不在会话中显示。[1]
属性值也用于既有配置的匹配。来源说，系统利用这些值，确定是否已经存在与用户在配置会话中所作选择相匹配的配置。类型说明值可以怎样表达，状态说明会话中怎样显示或是否必须有值，这一段则问已有配置是否对应这组选择。三种说明围绕同一批属性，却分别保留了取值形式、条件身份及匹配关系，不是把一个已有配置的名称当作全部选择内容。[1]
本文只讨论所读公开数据模型，不运行配置会话、编写OML或实施生产BOM路线，也不根据软件匹配判定实物性能或安全。页面更新日不作首次发表日。[1]
信息来源
本文基于上述公开资料整理，未使用来源页面的图片、视频或嵌入媒体。