[
Lists Home |
Date Index |
Thread Index
]
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@allette.com.au>
> 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?
|
