Issue 212: binding defaulting clarification

One of the concerns raised regarding the proposed resolution to issue 
212 was that there might be a conflict or misalignment between this 
proposal and the defaulting strategy described in part 3. Because I was 
reviewing the documents part-by-part when making these comments, I 
wasn't aware of them, and I believe this is a legitimate concern.

Weighing the two approaches, part 3's is attractive because allows 
selectivity; i.e., one can specify some operation-specific properties, 
while still falling back to defaults for other properties in the same 
operation.

However, the approach taken in part three requires that every defined 
property specify a defaulting syntax; if it does not, there is no way 
to default that property, and properties will need to be duplicated 
throughout the different components of the binding.

The approach proposed for issue 212, on the other hand, is not 
selective; if you specify anything about an operation, the defaulting 
mechanism described no longer applies to that operation as a whole. 
However, there is no special accommodation required for properties to 
use this mechanism, unlike that described in part 3.

It might be possible to design a third option that is both selective 
and generic with respect to properties, but I'm concerned that the 
rules for such a defaulting scheme would be unnecessarily complex and 
therefore confusing.

As a result, unless the WG is interested in developing this third 
option, I recommend that Issue 212 be dropped with no action, because 
the approach proposed for it is less powerful than that described in 
part 3.

Regards,

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Received on Monday, 21 June 2004 20:09:20 UTC