Constraints on grandchildren

From W3C Wiki
Revision as of 02:32, 31 March 2006 by CMSMcQ (Talk)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Constraints on grandchildren (a co-constraint use case)

Make the children allowed in an element depend not just on the element but on the context in which it appears (so the grandchildren depend in part on their grandparent).

source: Paul Kiel [1]

Description

   I have a question ... regarding context-specific use of components.  Let's take the element <Person> in a human resources context.  (BTW - <Person> is too broad a concept to actually encode, this is only for discussion).  We may want to use a <Person> in many contexts, where some of its components are required in one and not in another.  Let's say we have two transactions of Person below (and that all children are stand alone components):
   Transaction 1:


<Transaction_1>
    ...
    <Person>
         <Name/><!-- required -->
         <Skills/><!-- required -->
         <Height/><!-- required -->
         <Weight/><!-- required -->
    </Person>
    ...
</Transaction_1>


   In this transaction, we need all the data about this person to do the
   transaction.
   Transaction 2:
<Transaction_2>
    ...
    <Person>
         <Name/><!-- required -->
         <Skills/><!-- optional -->
    </Person>
    ...
</Transaction_2>


   In this transaction, we only need a name of the person and the skills are
   optional.  The Height and Weight have no meaning 
   in this context and can't occur.
   Given these kinds of scenarios, are we to:
  1. have many versions of <Person> with different occurrence constraints based on context (many small blocks and few big blocks)
  2. build a <Person> that has everything and list contextual constraints externally (the OAGIS 8 design)
  3. build an abstract <Person> and derive by restriction (the best practices argues quite effectively not to do this)
  4. decoupling of efforts. Create an abstract <Person> with everything in one schema and no constraints. Meanwhile, in actual transactions, use context-specific <Person> with constraints as needed which matches the abstract <Person> but without doing it explicitly via restriction. This way you get to build a broader model for others to reuse but without the tight coupling that is expressed on Roger's Best Practices site.
  5. others?

Analysis

HT

really an xsi:type case?

MH

Inferring that the Person elements differ from one parent element to another, local elements looks like a fine solution, perhaps with types that are derived from some base type. MH

MSM

Local elements work, as MH notes, for the scenario actually described. Their use gets more complicated when the constraints in question need to pass down to descendants nested arbitrarily deep, as in the related HTML input element use case.

Possible solutions

Relax NG

Schematron

Check clause

SchemaPath

Conditional Type