Question

我没有找到任何关于网络上xml标记长度限制的提及。我正在寻找构建XML Schema，作为第三方向我们发送数据的规范。

Schema（和数据）应该符合我们的自定义本体/数据字典，它是分层的，用户可自定义的。

自然映射用于层次结构中的节点，用于命名XSD / XML中的类型和标记。因为本体中的叶节点名称不一定是唯一的，我正在考虑将层次结构中节点的完整路径编码为标记名称，适当地修改XML词法规则。

因此，如果我的本体有多个'lisa'节点意味着不同的东西，因为它们位于层次结构中的不同位置，我可以使用节点的完整路径来生成不同的XML类型/标签名称，因此您可以拥有

 <abe_homer_lisa> simpsons lisa ... </abe_homer_lisa>
 <applei_appleii_lisa> ... apple lisa </applei_appleii_lisa>
 <mona_lisa> and paintings </mona_lisa>

...同一文件中任何不同'lisa'类型的数据没有歧义。

我无法在网络上找到任何指定最大标记长度的内容（或符合标准的引擎支持的最小标记长度）。（XML here）的词法规则的总结

同样的事情was asked about attribute length如果标准没有规定属性的限制，那么我怀疑标签是否存在，但可能存在实际限制。

我怀疑即使是一个实际的限制也会比我的需要大得多（我希望大多数时候事情都小于255个字符）;基本上，如果Java XML处理器，标准ETL工具和通用XSLT处理器都可以处理比这大得多的标签，那么它就不会成为问题。

Answer 1

我认为你不太可能找到无法处理1K字符名称的工具，此时你会遇到严重的性能和可用性问题，而不是硬限制。

但你的设计是错误的。 XML是层次结构的，利用事实而不是试图对抗它。

Answer 2

我知道标签名称长度没有限制，但是根据尝试解析XML的工具可能会有一些实现限制，即使XML规范可能没有提到任何限制。

另一方面，为什么不使用XML的原生＆amp;固有的等级结构。为什么要将所有内容编码为＆lt; abe_homer_lisa＆gt;而不是将其编码为：

<abe>
    <homer>
        <lisa>simpsons lisa</lisa>
    </homer>
</abe>
<applei>
    <appleii>
        <lisa> ... apple lisa </lisa>
    </applei>
</appleii>

Answer 3

我强烈建议使用已建立的XML机制来区分元素，即使用命名空间。那样你会有例如。

<lisa xmlns="http://example.com/simpsons">..</lisa>

<lisa xmlns="http://example.com/apple">...</lisa>

W3C模式语言以及XSLT和XPath都完全支持名称空间。

Answer 4

根据Michael Kay（某位XML专家）和Mihai Stancu的评论，我会说我原来问题的答案是：

没有官方限制
可能支持1000多个字符作为绝对最小值的工具
可能遇到性能问题[给定一个XML工具处理这些文件必须在很长的字符串上进行大量的字符串索引和比较]和之前的可用性方法
XML命名空间和/或使用文档树的结构来提供区分上下文可能是更好地“标记”标记名称的方法

我回答了关于合法标签长度的非常具体的问题，因为我发现同样的问题是关于属性长度而不是标签，我认为可能值得“周围”回答以防其他人谷歌搜索它。感谢所有受访者。关于我的设计是否合理的有效点;我将在其他地方解释其中的理由。

Answer 5

感谢那些指出可能有更明智的方法来解决潜在问题的人（确保XML模式中的类型/标记名称是唯一的）。

重新使用节点层次结构来提供上下文：我同意这通常是合适的。但是（在q中我没有真正解释我的精确问题域）在这种特殊情况下，我必须处理的树结构数据字典中用户可配置的项目分组是非常随意的，几乎与任何无关字典描述的数据中的关系。

所以在

 <abe>
   <homer>
     <lisa>lisa1</lisa>
   </homer>
 </abe>

示例另一个lisa节点应该在同一个本地节点下，还是在另一个节点下？本垒打应该在同一个abe节点下吗？在所讨论的数据的情况下，区别或多或少是毫无意义的：它就像根据在特定书中恰好引用的索引的页面对数据进行分组。我想我可以随意拨打电话并将其锁定在XSD中。

如果使用类似XSL的东西来提取数据那么无关紧要，// abe / homer / lisa将获得所有的lisa节点，而不管它们是如何组合在一起的。在实践中，有人可能会从CSV文件或其他任何内容生成这些内容，因此我希望尽可能采用平面结构。

同名命名空间：尽管它们是为此目的而设计的（为文件提供上下文并确保在文件中将不同类型的数据捆绑在一起时意外冲突不会引起歧义），实际上它们会添加对于从源系统生成数据的人来说，这是一个额外的复杂层。

在我的确切情况下，我希望这个任意分组中的名字冲突不太可能（并且反映使用不当），因此只需要合理处理，而不会对大多数情况施加不当惩罚

Answer 6

与传统观点相反，我强烈建议不要使用所谓的XML命名空间机制。在更长的时间内，它会让你痛苦。对命名空间说不。你不需要它们。

你的直觉，即元素可以通过它们的上下文来区分 - 在这种情况下，由它们的“路径”表示 - 是correct。但是，将整个路径编码为元素名称的想法可能不是最佳的。请考虑使用简单名称以及用于保存上下文或路径的属性。（将此属性命名为“context”或“path”或更令人回味！）这足以区分其含义。[*]

对于不同的内容模型，您可以使用相同技术的变体。为每个不同的类型提供一个方便的名称，并将“真实”名称记录在另一个名为“本体”的属性中。

至于你的问题，XML规范没有对名称的长度设置任何固有的限制，尽管出于纯技术原因，你可能会发现某些地方引用了65536个字符的限制。同样的“限制”也可能适用于属性值文字的长度。平均每个原子名称20个字符，20个级别的层次结构仍然会少于500个字节的路径，因此您可能几乎不用担心。

[*]注意：这种技术实际上很老，但在XML思维空间中几乎完全被遗忘了。例如，在HTML中，有一个名为INPUT的元素类型可以涵盖所有类型的GUI控件，但由于“type”属性

正式或实用的XML标签长度限制？

6 个答案: