Issue 220: Document interface extension semantics

I had an AI to start discussion on Issue 220.

Looking over the current drafts, I think there isn't a technical issue 
here, but instead an editorial one. Namely, information about interface 
extension is spread throughout the draft, making it difficult to get a 
good picture of how it works.

I think there are a couple of directions we could go to clarify this; 
if I can get a sense of what other people think, I'll be glad to make a 
concrete proposal.

1.) Add a new subsection of section 4 - Modularising WSDL Descriptions, 
entitled "Extending Interfaces," with appropriate text and references. 
I imagine this section would be fairly short.

2.) Add text to the note at the end of 2.2.3 that references the 
extension-related material in 2.3.1 and 2.4.1.

Thoughts?

Separately, I note that the rules for deriving extended operations, 
faults, properties and features are defined as part of the mapping from 
the Infoset, and not purely upon the component model, even though there 
is an {extended interfaces} property that would allow this. Was this 
intentional -- i.e., if there was one day a mapping from another 
serialisation, could it define a different way to compose extended 
interfaces?

I don't think this is a big deal, it just seemed odd that it was 
defined in this way.

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

Received on Monday, 5 July 2004 16:03:12 UTC