Simon Laws wrote:
<snip>
I think we should try and keep this as simple as possible. At least
for now. Saying interfaces have to be the same is pretty clear. I'm
trying to identify those cases where we deviate from this and raised
the OMElement case as we have explicit tests for it so it must be
important to someone.
I don't want to disable features if I can avoid it and there is a good
reason for them (and we can justify them in the context of the spec or
a Tuscany specific extension to the spec). On the other hand I don't
want to go in and support a lot more flexibility that people are not
asking us for and seem tricky to implement.
Simon
Yes, +1 to "keep it simple".
Let's get the really simple case working first.
Then if there are some real situations where we need something different, let's examine them
carefully and make a proposal for something more complex only if it really brings benefits.
I think this discussion thread already started to touch on the complexities of permitting
subclasses. Let's not go there unless we have to.
In the Web services, XML document exchange, world, extensibility is quite often handled by means of
explicit extension points within the document structures - similar to the way in which SCA allows
extensions of composite documents - the composite document is still a composite document (and not a
subclass of the document) even when it contains extension elements.
Yours, Mike.
