可能没有任何实际用途,但我想知道是否有可能针对xsd验证属性。我使用xsd.exe从架构生成了一个cs文件,但没有验证逻辑被带到例如...
<xsd:element type="Text_Key" name="LPI_Key"/>
</xsd:simpleType>
<xsd:simpleType name="Text_Key">
<xsd:restriction base="xsd:string">
<xsd:length value="14" fixed="true"/>
<xsd:pattern value="[0-9][0-9][0-9][0-9][LXC][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]"/>
</xsd:restriction>
Generates
private string lPI_KeyField;
也许我错过了一些东西,但我会认为这是可能的。我知道我可以验证我是否然后将属性转换为xml但这似乎是一个向后的步骤,因为我说它可能没有任何实际用途,但它似乎使得如果验证逻辑已经存在,为什么不使用它。 在属性上验证id的原因是我可以告知用户他们输入的值是错误的,而不是等到输入所有值并且他们在转换为xml并验证之前点击提交。希望这样做有意义,如果我错过任何明显的教程或任何我想说的我已经谷歌搜索但我回来的是'验证xml对抗xsd',有时只是知道关键字在谷歌搜索中有所不同。
回应Romil:
感谢您的回应。虽然我同意RegEx会执行所需的验证,但如果xsd.exe会为您生成,那就太棒了。但正如我原来的帖子所见,没有验证结果,你可以说我只是懒惰但我认为它试图减少事故和混乱。在整个应用程序,数据存储区等中使用一组验证规则意味着没有验证错误会禁止用户(在上面的情况下,xml架构是一个我无法控制的预定义架构,并且我确定这是一个许多人也会联系的案例)。如果我要编写自己的正则表达式验证(并且使用作为参考点的模式非常大)并且xsd验证规则在哪里更改,那么我将不得不更新我的正则表达式中的所有更改(承载请注意,原始RegEx可能会阻止用户输入有效数据,直到执行更新为止。现在,如果我能够直接验证xsd,那么只需将旧旧的一个放入并放置新的(为了这个问题,我们可以假设只有验证逻辑改变了;-))和之后,该属性的所有值仍然与xml字符串中的值相同。
答案 0 :(得分:0)
使用RegEx验证属性值。
XSD仅针对XML进行验证。