我正在尝试对DocBook进行微妙的自定义，我怀疑通过子类化<informaltable>元素最容易解决这个问题。有几个语句暗示使用role属性对DocBook元素进行子类化是可能的。
示例1 - 来自DocBook 5.1：权威指南 - 自定义DocBook
在DocBook中几乎所有元素上都可以找到的role属性是一个可用于子元素子类的文本属性。
示例2 - 来自DocBook 5.1：权威指南 - DocBook元素参考
虽然角色是在所有DocBook元素上出现的常见属性，但定制者会发现它不是任何“常见属性”模式的一部分。它的参数化方式不同，因为能够在不同的元素上独立地继承角色是很有用的。
示例3 - CERN - 使用DocBook编写文档
大多数DocBook标记包含一组通用属性。最常用的这样的公共属性是lang，它指定元素内部数据的语言，id标记元素以便它可以被其他元素引用，而role，允许一个元素子类化，以使其成为信息方面更具体。
“扩展docbook元素角色属性”的Google搜索组合会显示有关处理新元素的模板的页面，但似乎没有显示除下面的自定义示例之外的任何页面，甚至考虑使用role子类化元素属性。
存在examples自定义现有DocBook元素的格式，但这些是XSLT自定义，并不代表扩展DocBook架构。
还存在an example添加<sect6>元素，但它似乎太冗长而不是一种有效的子类化方法，我怀疑从技术上说这个例子根本不是子类。此外，该示例似乎没有对role属性进行任何特殊使用。
role属性进行子类化吗？从上面的例子看来，DocBook模式是专门设计的，以便使用role属性来促进元素的子类化，但是，似乎没有发布具体的例子。
我是XML和DocBook的新手。子类化一个DocBook元素是如此微不足道，以至于它没有被注意到？如果是这样，有人可以展示它是如何实现的吗？
使用role继承DocBook元素是一个不好的想法吗？如果是这样，为什么不起作用？
注1：
是否将<informaltable>子类化为解决原始问题的正确方法完全是另一个问题。
注2： 我的问题中有更多的超链接，但显然我的声誉不允许我发布超过2 :(
答案 0 :(得分：1)
TDG的从上面的例子看来，DocBook模式是专门设计的，以便使用role属性来促进元素的子类化，但是，似乎没有发布具体的例子。
Example 5.14是一个非常具体的示例，展示了如何约束role元素上的<procedure>属性，以便只允许两个值（默认情况下，允许任何值） ）。此自定义需要修改架构。如果您愿意，可以使用<informaltable>执行类似操作。
没有什么可以阻止你使用像
这样的东西<informaltable role="myspecialtable">
...
</informaltable>
这是最简单的“子类化”;不需要更改架构。如何解释或处理role="myspecialtable"完全取决于你。
还存在一个添加
<sect6>元素的示例，但它似乎过于冗长而不是一种有效的子类化方法，我怀疑从技术上讲，该示例根本不是子类化。此外，该示例似乎没有对角色属性进行任何特殊使用。
那么您对子类化的想法是什么？
也许术语“子类化”可能有点误导。 DocBook是一个标记系统，而不是一种编程语言。子类化（自定义）DocBook元素和用Java或C ++创建子类之间的类比不应该太过分。
role没有什么神奇之处。它只是一个没有预定义语义的属性。您无需对其执行任何特殊操作即可创建DocBook自定义。
是否对DocBook元素进行子类化是如此微不足道以至于没有注意到它？
为什么这么说？整个"Customizing DocBook"章节是关于DocBook元素的自定义。这不是一个不被注意的东西。
使用角色对DocBook元素进行子类化是个不行的好主意吗？
它确实有效，但可能不是你想象的那样。
如上所述，只需通过确定元素上role属性的特定值并在文档中使用它，您就可以创建该元素的子类（自定义，变体）。而已。
如何使用自定义元素 - 如何对其进行转换，过滤，可视化等等 - 是另一回事。