[Home] [By Thread] [By Date] [Recent Entries]
Four approaches spring to mind: A) Add constraints in <appinfo> elements, in terms of types, using your own language. Then create a postprocessor that generates the equivalent constraints in terms of some other schema language (WXS' integrity/uniqueness constraints, Schematron, XLinkIt). Validate using that generated schema. B) Run your document through a transformation that converts all element names with their type names. Then validate that against a WXS schema with uniqueness/integrity rules written using these type names as element names. C) Fulminate & vituperate at appropriate intervals. D) Go on holidays Cheers Rick Jelliffe Christian Nentwich wrote: >All, > >we are currently looking at where uniqueness and key constraints can >be applied to our schema. > >The problem is, the schema is semantically very rich, big on element >reuse, and huge. As a consequence, most of the schema is expressed in >terms of data types. > >There are a few constraints that have to hold for all instances of those >data types, for example, "elements of type A must reference existing elements >of type B", but schema lets you express key/uniqueness only *per-element*, >not *per-datatype*. This is probably prohibitive from a schema management >perspective. > >Is there any way around this, or a best practice approach to addressing >this? > >
|

Cart



