Re: Re: elements with different types in a <choice>

Thank you for the good and complete explanation. Both solutions works however I'm not sure I fully understand the issue with "afoul of consistency rules". To me the choice model identifies a finite number of alternatives so the validator should be able to verify that my instance element matches one of the alternatives. In support of my point, Relax NG allows co-occurrence and it validates document against it.

Please let me know if what I said makes any sense.

Thanks

Alessandro


   -------Original Message-------
   > From: Mary Holstege <holstege@mathling.com>
   > Subject: Re: elements with different types in a <choice>
   > Sent: 09 Dec 2003 16:54:21
   >
   >  There are two ways to go about this:
   >  (1) same element name, different types
   >  (2) different element names
   >  
   >  You cannot implement strategy one with a choice among similarly named elements
   >  of different types; this will run afoul of the consistency rules in schema.
   >  Think of it this way: how is the validator to know which one you meant? In
   >  general, you really cannot tell. What you _can_ do is make all your variants
   >  subtypes of some master type, which you can make abstract if you like, and then
   >  use xsi:type to indicate which you mean.
   >  
   >  So:
   >  
   >  
   >  ...
   >  ...
   >  ...
   >  
   >  You declare field to be of type baseType and firstType to be derived from it.
   >  
   >  
   >  ...
   >  
   >  
   >  
   >    
   >            or restriction or whatever
   >        ...
   >    
   >  
   >  
   >  
   >  
   >  
   >    
   >        
   >    
   >  
   >  
   >  (2) You give your different types different names and use substitution groups
   >  to get the nice general definition.
   >  
   >  So:
   >  
   >  
   >  ...
   >  ...
   >  ...
   >  
   >  You still need to have the types of these elements derive from baseType.
   >  
   >  
   >  ...
   >  
   >  
   >  
   >    
   >            or restriction or whatever
   >        ...
   >    
   >  
   >  
   >  
   >  
   >  
   >  
   >  
   >    
   >        
   >    
   >  
   >  
   >  
   >  Using substitution groups allows you to add additional variants quite easily.
   >  
   >  
   >  Pros and cons:
   >  (1) If you want to dispatch based on element names, you have consistent element
   >  names. A bit less is required in the initial mechanics in the declarations.
   >  OTOH, you need to do a secondary dispatch based on the xsi:type anyway, and
   >  your instances are cluttered up with type names which makes it harder to apply
   >  different schema to them, or upgrade to new versions. The type names become
   >  part of your interface, in essense, so you have to use named types.
   >  
   >  (2) You can dispatch directly on element names, if you know what all the
   >  elements in the substitution group might be. Or you can dispatch based on the
   >  type instead. Initial setup is a little more involved -- you must define both a
   >  type relationship and an element relationship -- but adding more variants is
   >  easier. You instance syntax is cleaner and more flexible. You can use anonymous
   >  types if you want to and keep only the element names in your interface.
   >  
   >  -- Mary
   >      Holstege@mathling.com
   -------Original Message-------

Received on Wednesday, 10 December 2003 06:13:07 UTC