XML、DTD：如何使顺序不重要
我开始使用 XML 文件和解析器作为存储数据的便捷方式，
我想使用 DTD 在 xml 文件到达时检查它们的结构。
这是我的 DTD 文件
< ?xml version="1.0" encoding="UTF-8"?>
< !ELEMENT document (level*)>
< !ELEMENT level (file,filelName?,fileNumber?)>
< !ELEMENT file (#PCDATA)>
< !ELEMENT filelName (#PCDATA)>
< !ELEMENT fileNumber (#PCDATA)>
（请注意，fileName 和 fileNumber 实际上是纯可选的）
，
<document>
<level>
<file>group1file01</file>
</level>
<level>
<file>group1file02</file>
<fileName>file 2</fileName>
<fileNumber>0</fileNumber>
</level>
...
因此所有这些都可以正常工作。 （我现在使用 eclipse“验证”选项来测试它）
我会得到一个奇怪的错误
但是，在测试时，如果我
<level>
<levelName>Level 2</levelName>
<levelNumber>0</levelNumber>
<file>group1level02</file>
</level>
更改行的顺序，
，Eclipse 拒绝验证它......我想知道这是否是Eclipse 的问题或者顺序是否确实很重要。
如果顺序很重要，我如何更改 DTD 才能使其正常工作，而不管元素的顺序如何？
我无法真正更改 XML，因为我已经编写了所有 XML 文件和解析器（我知道我做错了，哈哈）。
I started off using an XML file and a parser as a convenient way to store my data
I want to use DTD to check the structure of the xml files when they arrive.
Here is my DTD file
< ?xml version="1.0" encoding="UTF-8"?>
< !ELEMENT document (level*)>
< !ELEMENT level (file,filelName?,fileNumber?)>
< !ELEMENT file (#PCDATA)>
< !ELEMENT filelName (#PCDATA)>
< !ELEMENT fileNumber (#PCDATA)>
(note that fileName and fileNumber are actually purely optional)
and
<document>
<level>
<file>group1file01</file>
</level>
<level>
<file>group1file02</file>
<fileName>file 2</fileName>
<fileNumber>0</fileNumber>
</level>
...
as such all this works fine. (I use eclipse "validate" option to test it for now)
however while testing I got what I think is a wierd error
if I do
<level>
<levelName>Level 2</levelName>
<levelNumber>0</levelNumber>
<file>group1level02</file>
</level>
changing the order of the lines, Eclipse refuses to validate it ...
I was wondering if this was a problem with Eclipse or if the order is actually important.
If the order is important how can I change the DTD to make it work no matter the ordering of he elements?
I can't really change the XML because I already have all the XML files and the parser written (I know I did it the wrong way round lol).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
正如 Roger 所说，只有有序列表，但您可以使用运算符 OR
|来定义所有接受的组合查看 这里，选择部分有一个示例
As Roger said, there are only ordered lists, but you can use operator OR
|to define all accepted combinationsLook here, there is an example in the section Choices
在 DTD 中声明具有出现约束的无序列表通常会导致声明冗长或复杂。造成这种情况的一个重要原因是 DTD 必须是确定性的，因此即使切换到 XML 模式也不一定有帮助。
以下是元素
：
Declaring unordered lists with occurrence constraints in DTD will often result in long or complicated looking declarations. One big reason for this is that DTDs must be deterministic, therefore even switching to XML Schemas don't necessarily help.
Here is a DTD declaration for element
<level>that contains:<file>element<fileName>elements<fileNumber>elementscode:
如果您不太关心有效性，则可以使用
ANY关键字：我也遇到过类似的问题 这里，可能会出现这两种情况：
我找到的唯一解决方案是：
也许有更好的解决方案，但它对于我的特定问题效果很好。
You can use
ANYkeyword if you don't bother too much about validity:I have faced a similar problem here, this two cases may appear:
The only solution I found was this:
Maybe there are a better solution, but it works fine for my particular problem.
对于 DTD，子节点必须按照元素定义中列出的顺序出现。除非您想升级到 XSD 架构，否则无法允许替代排序。
附录：根据@Gaim，您可以使用 (a,b,c...)|(b,a,c...) 语法提供替代订单，但这对于比方说，超过 3 个嵌套元素，因为任意顺序允许阶乘数量的排序 — 3 个元素为 6 个，4 个元素为 24 个，5 个元素为 120 个 — 并且巧妙地使用 ?运算符肯定会导致对奇怪情况的错误验证。
With a DTD the child nodes have to appear in the order listed in the element definition. There is no way to allow for alternative orderings, unless you want to upgrade to an XSD schema.
Addendum: Per @Gaim, you can offer alternative orders using the (a,b,c...)|(b,a,c...) syntax, but this is not really practical for more than, say, 3 nested elements, since an arbitrary order allows for a factorial number of orderings -- 6 for 3 elements, 24 for 4 elements, 120 for 5 elements -- and clever use of ? operators is sure to result in false validation for strange cases.
如果您可以猜测元素的子元素数量的合理上限，那么解决该问题的方法非常肮脏。遵循 0-3 个子项的示例：
因此，您允许元素“myUnorderedElement”具有 0-3 个选项 1、选项 2 或选项 3 中任意类型的子项。
If you can guess sensible upper-bound for the number of children for your element, than there is extremely dirty way how to overcome the problem. Follows the example for 0-3 children:
Thus, you allow the element "myUnorderedElement" to have 0-3 children of any of type option1, option2 or option3.