Re: [dss] Profile Integration proposal

[Andreas Kuehne <kuehne@klup.de>]

Trevor, Paul !

[...]


>> The alternative would be Andreas's suggestion below to allow the 
>> requestor
>> to indicate both 'wss' and 'pws' in its request and place the burden of
>> interpretation on the DSS server. We would likely need to define an
>> corresponding fault message for 'no intersection of profiles'.
> 
> 
> I don't like the idea of "auto-merging" profiles.  Different profiles 
> will probably conflict, so if you want to combine them, human 
> intelligence will be needed to figure out which requirements from each 
> take precedence, and produce a new profile documenting this.
I'll expect human intelligence will be needed anyway, especially for implenting the different profiles :-)


The implementor has to think about every possible combination of profiles anyway ! Whether we precombine them at specification time or they are 
given at runtime. The decision for the implementor is the same : 'Do I want to implement profile x in combination with profile y ?'

My concern is that we try to make a decision that should better be left to the implementor. Let the smart programmers and the bold salesmen 
decide which combination are relevant.


[...]
> 
>> >However, if a particular concrete profile wants to subclass several
>> >incompatible horizontal profiles, then it could define some
>> >new optional
>> >input(s) as selectors to switch between
>> >policy-wise/non-policywise, German
>> >Sig-Law/Belgian sig-law/French Sig-Law, etc..  I think it
>> >needs to be up to
>> >the concrete profile to define these selectors, not the core,
>> >since the
>> >details of what they mean, how many of them are needed, etc.,
>> >will vary.
>>
>> But we don't want different concrete profiles defining unique switching
>> mechanisms. The URI should be the flag.
> 
> 
> That's where we get the combinatory explosion, if we need a unique URI 
> for every combination of options.  For example, if a profile can be used 
> with:
>  - policy-wise / non-policy-wise
>  - German sig-law / Dutch sig-law / French sig-law / Belgian sig-law
>  - Asynch / Non-Asynch
> 
> That would be 16 URIs.  So it would be better to internalize these as 
> independent optional inputs, somehow.
> 
> I dunno.  We may be worrying about something that isn't really a problem 
> yet.  I think we should wait for the concrete profiles to develop 
> further, and see how the concrete profiles choose to use the abstract 
> profiles, before deciding on anything drastic (like sending multiple 
> URIs to the server).

Another concern of precombining profiles :  If someone discoveres the need for a new combination it will take a complete standardisation cycle 
to define it, didn't it ? This would hamper the implementor a lot !

Greetings

Andreas