Cart
[Home] [By Thread] [By Date] [Recent Entries]
I think B doesn't work, because of the unique particle attribution constraint. However, since the problem is the difficulty of hand-maintaining the mapping of type constraints to element-using-type constraints, automating the translation by A or any equivalent sounds like a really good idea. Rick probably thought it was obvious, but you could take a hint from Schematron and implement your language as foreign-namespace elements within your existing schema, use XSLT to translate the annotated schema into one which maps the constraints in a suitable way and use the translated XML Schema (or whatever kind of schema you generate) to validate your documents. I think it's fair to say that this sort of meta-approach to the restrictions of various XML tools is a "best practice". Of course, C and D are very common practices, too, and not inconsistent with A. ;-} Bob Foster http://www.xmlbuddy.com/ From: "Rick Jelliffe" <ricko@a...> > 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?
|
