Xml 是否有理由定义基于xsd:token或xsd:string的类型

我正在处理许多xsd文件。我注意到有几种类型定义是基于xsd:token和xsd:string的，没有任何限制。比如说

<xsd:complexType name="BaseString">
    <xsd:simpleContent>
        <xsd:extension base="xsd:token"/>
    </xsd:simpleContent>
</xsd:complexType>

我想知道这种定义是否有原因。为什么不使用xsd:token或xsd:string而不是BaseString类型？

---

有什么想法吗

它看起来不是很好的设计，但它取决于一个更广泛的背景，您没有用这个例子向我们展示

我见过定义专门ID的模式。假设您的域具有

FooObjects

。它们由

FoodObjectId

标识。通常情况下，

foooobjectid

将被定义为类型

foooobjectidtype

。该类型又可以定义为

xsd:token

或

xsd:string

的扩展。该类型将FooObjectID区分为不同于（因此处理方式也不同于）香草字符串

有时，当ID是实际上是复合值的“智能ID”时，您会看到这种情况。想象一下，客户ID看起来像：

CUST-VA-3391

。在所有数据管理中，一个典型的糟糕设计是这些“智能钥匙”，它在一个ID中编码多条信息（Virginia customer#3391）。根据我的经验，这样一个ID的类型通常与这里的类型类似

添加人工类型是为了在这个特殊的东西和普通字符串之间建立区别，但是懒惰导致缺少与普通底层类型（xsd:token，xsd:string）的限制/区别

---

底线-您创建派生类型的部分目的是为该类型注入一些额外的语义；它不是普通字符串，而是

foooobjectid

。但是好的实践往往会建议进一步的扩展/限制是合适的。

您显示的表单的定义帮助记录类型的预期用途，为其提供比xsd:token更具信息性的名称。它们也有助于防止不适当的派生和替换（帽子大小和测验分数可能都是小整数，但它们确实不能互换）

---

当然，正如FrobberOfBits所观察到的，通常有机会使用模式或其他方面进一步限制类型。如图所示的推导可能会错过这样的机会；我比FrobberOfBits更不相信这一定是糟糕设计的标志。

你的例子“帽子大小和测验分数可能都是小整数，但它们确实不能互换”——非常好。在一个简单的例子中，这说明了我想说的关于“给事物注入额外的语义”的观点。但是当我们在编程时，我们对帽子大小和测验等级都使用int，我们只是使用名称来区分它们。为每个变量定义一个类型是不合适的。当使用像jaxp这样的api为xml创建java类时，问题就出现了。如果我们是基于自定义（在我的示例中是baseString）类型定义帽子大小，那么我们将有一个继承自定义类型的类。但是如果我们使用xsd:string或xsd:int，那么我们将把它作为类中的一个字段或变量。Govan，我想你说的是你的xsd到Java类转换器不是很聪明。那是一种耻辱；这并不意味着帽子大小和测验分数在XML文档中可以互换。