XMLSchema 1.1 request: Allow derived complex types to follow an 'all' content model

I'd like to see some changes with respect to extend the ability to derive 
new complex types where the content model does not enforce a specific 
order.  This request may not fit within the scope of XML Schema 1.1 as 
you've defined it but please consider this for a future release if its not 
applicable to XML Schema 1.1.

Let me try to explain this one.  Please bear with me...

Our architecture supports a generalized plug-in model where a certain 
element may contain several different content models within it depending on 
the xsi:type attribute set in the parent element in the xml instance 
document.  We derive one type for each of the different content models 
req'd and derive that content model by extension on a base type that 
defines the general type.
For example, in our files we support different prefilters and a user can 
define zero or more of these in their settings file.  It looks something like:

input
  prefilters
     prefilter

We define one generic prefilter type and then define specific prefilter 
types derived from the generic prefilter type.
For instance, we might have a  videoNoiseReductionPrefilterType and a 
videoCroppingPrefilterType that are both derived by extension from the 
generic prefilterType.

As noted above, the order of the properties within each prefilter is 
unimportant. We would like our users to be able to set one or more 
properties w/o having to be concerned with the order so we use the 
'xsd:all' group.

 From the section 4.2 (Deriving Types by Extension) in the XML Schema Part 
0: Primer "the two content models are treated as two children of a 
sequential group".  This forces us to impose an ordering of properties on 
the user if we want to define properties in the base type.  That is, they 
have to specify base type properties before specifying properties from the 
derived type.

Ideally I would like to define some common properties in the base type and 
then extend properties for each of the derived types.  Something like this:

prefilterType
  name
  pluginName
  enabled

Then in a derived type, extend that with more properties:

videoNoiseReductionPrefilterType (base=prefilterType)
  noiseLevel

videoCroppingPrefilter  (base=prefilterType)
  left
  right
  top
  bottom


However, if we do this, the user (and our app) is forced to make sure the 
order of the properties are: (all base type properties first) and then (all 
instance prefilter type properties).  This is logic we do not wish to have 
in our application since it would force us make assumptions we do not wish 
to make and limit the generic nature of our architecture

Because of the limitations in the current XML Schema content model for 
deriving types based on extension, we end up hacking things like this:

Define base type with no properties:

prefilterType

Then in a derived type, extend that with all properties:

videoNoiseReductionPrefilterType (base=prefilterType)
  name
  pluginName
  enabled
  noiseLevel

videoCroppingPrefilter  (base=prefilterType)
  name
  pluginName
  enabled
  left
  right
  top
  bottom

This means we have to repeat the same properties many times and we cannot 
get the benefit of leveraging the common properties.

It would be nice if derived types could use a non-ordered content model
in some way.  Maybe that means that the content model of the two combined 
groups can be specified explicitly.
Thanks for the opportunity for feedback.  I'd be happy to provide more details.

Thanks,
Steve McMillen
Program Manager, RealNetworks
stevemc@real.com

p.s.  Just a word of praise for including the functionality to derrive 
types from base types.  This is a great capabilty.  Also, the key, keyref 
and unique elements are very useful in real-world sitautions.
Finally, thanks for the great work on writing the XML Schema Part 0: 
Primer.  It it was not for this document, some of these advanced features 
of XML Schemas would have gone unnoticed.  I have several books on XML 
Schemas and I've looked through a lot more and I've not found one that 
treats these advanced topics at all.

Received on Friday, 14 March 2003 09:33:13 UTC