3

スキーマ定義 (.xsd ファイル) 内のこの列挙が冗長であることを確認 (または反論) してください (2 番目の simpleType が 5 文字以下のものを通過させるため)。

<simpleType name="decision">
    <annotation>
        <documentation>It will decide the flow</documentation>
    </annotation>
    <union>
        <simpleType>
            <restriction base="string">
                <enumeration value="yes"/>
                <enumeration value="no"/>
                <enumeration value="maybe"/>
            </restriction>
        </simpleType>
        <simpleType>
            <restriction base="string">
                <maxLength value="5"/>
            </retriction>
        </simpleType>
    </union>
<simpleType>

アプリケーション全体にこれらのものがかなりあるので、最適化する必要があります。

4

2 に答える 2

1

表示されているのは、XSD作成者が、私が「拡張可能な列挙」と呼んでいるものに前方/後方互換性を提供するために使用するパターンです。

一部の人にとって、これは撞着語です。私にとっては、リストされている値以外の値を適切に処理するために、このコントラクトの実装を準備する必要があることを意味します。

契約設計者は、これらの特定のタイプについては、一部のコンシューマーが列挙値に関するビジネスロジックを持たない場合もあれば、そうである場合もあるという理由だけで、「フェイルファスト」拒否（通常はXSDバリデーターによって行われる）があってはならないと決定しました。

もちろん、最終的にはドキュメントを作成するための「紛らわしい」方法のようです... .NETのxsd.exe、svcutil.exe、Java JAXBなどのXSDからコードへの実装は非常に賢い（そうではない）と想像してみてください。それでも列挙型を作成し、、、、、およびその他を持ちyes、後者は他のすべての値のキャッチオールです。上記を仮定すると、これはまだ冗長であると見なされるのでしょうか。コードカバレッジの専門家はそれを気に入るはずです...nomaybe

于 2012-11-07T16:00:45.427 に答える
1

検証にスキーマのみを使用している場合は冗長です。

データバインディング、スキーマ対応のXSLT / XQuery処理、ドキュメント、インスタンスの生成、フォームの生成にスキーマを使用している場合は、この種の設計が役立つ場合があります。また、スキーマをより拡張可能/カスタマイズ可能にすることもできます。（しかし、これらは組合に関する一般的なポイントです。あなたの特定のケースが役立つかどうかはわかりません。）

于 2012-11-07T18:22:20.193 に答える