Lists Home |
Date Index |
I think B doesn't work, because of the unique particle attribution
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
From: "Rick Jelliffe" <firstname.lastname@example.org>
> 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,
> 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
> Rick Jelliffe
> Christian Nentwich wrote:
> >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
> >of type B", but schema lets you express key/uniqueness only
> >not *per-datatype*. This is probably prohibitive from a schema management
> >Is there any way around this, or a best practice approach to addressing