On Mon, Jul 16, 2012 at 12:27 PM, Kabir Khan
<kabir.khan@jboss.com> wrote:
On 16 Jul 2012, at 10:40, Emanuel Muckenhuber wrote:
>
> On 07/12/2012 11:16 PM, Tomaz Cerar wrote:
>> Question is do we even want to support this as currently there is no support for validating and enforcing this constraints.
>> only thing we have is that some manually written model defines it.
>> If we add support for this on RD and IMRR we should probably add support for enforcing / validating it.
>>
>> Also we have figured out that when we converted subsystem we have lost this information. Would it make sense to re-add it?
>
> IMO we should add the min/max-occurs descriptions back. Even if it might
> be too late to add proper validators, it still would fail during runtime
> or result in some unexpected behavior. Perhaps mgmt clients can use it
> as well and it end i see it as documentation of the intended purpose.
>
> I haven't looked at the implementation in detail, but perhaps we can
> even have some sensible defaults - that a wildcard address would default
> to 0...n, otherwise to 0...1? This should be true for most of the cases
> and we only need to change the ones where this does not apply.
That's a good point - this is more important for wildcards. When the children are 'predefined' for a type they are either there or not. I'm not sure if there is anything to specify if a particular predefined child is optional or not though?
We could easily add support for some sensible defaults but adding this without support for overriding it would create even more chaos.
For examples there are cases where you have wildcard definition (i.e element=*) but it must always have 4 children, no more no less.
TBH this should be solved by different definition (i.e. :element=value1,element=value2,..) but still definitions like this exists.
So we are back to how to sensible add this information RD/MRR?
--
tomaz