これには実際の使用はないかもしれませんが、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に変換して検証するのではなく、値を入力しているときに何かが間違っていることをユーザーに通知できるようにするためです。うまくいけば、これは理にかなっており、明らかなチュートリアルや言いたいことを見逃した場合は、グーグルで検索しましたが、返されたのは「xsdに対してxmlを検証する」だけでした。
ロミルへの返答:
返信ありがとうございます。RegEx が必要な検証を実行することに同意しますが、xsd.exe がそれを生成してくれるなら、それは素晴らしいことです。しかし、私の元の投稿に見られるように、検証は引き継がれません。私は怠け者だと言うことができますが、事故や混乱を減らそうとしていると思います. アプリケーション、データストアなどで一連の検証ルールを使用することは、検証エラーがユーザーを禁止しないことを意味します (上記の場合、xml スキーマは定義済みのスキーマであり、私は制御できず、これが多くの人が関係するケース）。私が独自の正規表現検証を記述し (参照点として使用するスキーマは非常に大きい)、変更する xsd 検証ルールを作成する場合、次に、正規表現のすべての変更を更新する必要があります（元の正規表現では、更新が実行されるまでユーザーが有効なデータを入力できない場合があることに注意してください）。xsd に対して直接検証できた場合、古いものを交換して新しいものを配置するだけで済みます (この質問の目的のために、検証ロジックのみが変更されたと想定できます ;-)) そしてプロパティのすべての値は、xml 文字列に含まれる値と同じままです。