- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Fri, 15 Nov 2002 10:02:43 -0800
- To: <www-ws-desc@w3.org>
-------------------------------------------------------
Tuesday 12 November
-------------------------------------------------------
Present:
David Booth W3C
Allen Brookes Rogue Wave Software
Roberto Chinnici Sun Microsystems
Glen Daniels Macromedia
Youenn Fablet Canon
Steve Graham Global Grid Forum
Martin Gudgin Microsoft
Tom Jordahl Macromedia
Jacek Kopecky Systinet
Philippe Le Hégaret W3C
(phone) Amelia Lewis TIBCO
Steve Lind AT&T
Kevin Canyang Liu SAP
Jonathan Marsh Chair (Microsoft)
Jeff Mischkinsky Oracle
Dale Moberg Cyclone Commerce
(phone) Jean-Jacques Moreau Canon
Don Mullen Tibco
Arthur Ryman IBM
Adi Sakala IONA Technologies
Jeffrey Schlimmer Microsoft
Igor Sedukhin Computer Associates
William Vambenepe Hewlett-Packard
Don Wright Lexmark
Joyce Yang Oracle
Observers:
Francisco Curbera IBM
Martin Chapman Oracle
Scribe: Arthur
Topics remaining from yesterday 1) output operations 2) fault name uniqueness. Leave these and continue with today's agenda.
09:30 Importing Schema into WSDL
(issue-importing-documents-in-same-namespace [20])
Proposal for wsdl:import and wsdl:include [21]
Proposal for wsdl:using [22]
Gudge: if semantics don't follow schema, then use a different name, e.g. <use>. The problem is how to combine definitions from the same namespace. Schema uses <include> for same namespace, <import> for different namespace. Location is required on <include> but optional on <import>. <import> allows you to refer to components of a namespace. Location on import is not required since some namespaces will be well known and the WSDL processor won't have to retrieve them from a location. <include> is a way to break up a WSDL document into several documents. <include> has a required location attribute. <import> has a required namespace attribute and an optional location attribute. In schema, you must <import> a namespace in order to refer to its components via QNames.
Marsh: Sanjiva asked for an explanation behind <include> and <import>, observed the rules were hard to understand, and proposed a simpler, single construct
Glen: with a single construct, e.g. <using>, the processor gets the document and processes it based on the namespace it contains
Marsh: its clear that there is confusion about the semantics of schema <include> and <import>
Tom: arguments for simplification are not compelling
Paco: we should simplify the task of authoring WSDL
[Gudge: Why is having a single, overloaded, construct 'simpler' ?]
Paco: a single construct would be simpler
Marsh: tradeoff is consistency with schema versus fewer constructs
JacekK: a single construct is not necessarily simpler
Gudge: in schema you can't have two <import>s for the same namespace (and expect processors to handle it
Straw poll:
Option 1: Import & include (18 votes)
Option 2: Using (3 votes)
Marsh: those who voted for 2) can live with 1) ==> we have a consensus
DECISION: to have 2 constructs.
Further import questions:
Adi: does this mean we can <import> a schema in WSDL?
Marsh: use a schema <import> inside the <types> which was added in WSDL 1.2
Gudge: will confirm that <import> is a global element of schema schema so we can refer to it from the WSDL schema
Marsh: we can have multiple <import> and <schema> inside <types>
Roberto: confirmed that <import> is a global element of schema schema
[20] http://www.w3.org/2002/ws/desc/2/06/issues.html#xissue-importing-documents-in-same-namespace
[21] http://lists.w3.org/Archives/Public/www-ws-desc/2002Oct/0067.html
[22] http://lists.w3.org/Archives/Public/www-ws-desc/2002Oct/0114.html
-------------------------------------------------------
10:00 Equivalence of top-level components [23] (Sanjiva)
Marsh: What are the use cases? Is name-based or structure-based equivalence required?
Jeffsch: one use case is for a canonical form for use with digital signatures. Not a lot of discussion on this
Marsh: can we drop this work item?
[DonM: Req Spec: 4.11 Security. R115: The WG specification(s) SHOULD define an equivalence relation on Service descriptions. (From SW. Last discussed 17 Oct 2002.)]
Tom: is Sanjiva's solution controversial?
Marsh: no, it might not hit the right use case
Dmoberg: Arthur had a use case
Arthur: my use case is reconstructing WSDL definitions from UDDI, which is handled by Gudge's abstract model. UDDI must respect the abstract model when round-tripping, i.e. what I publish into UDDI must have the same AM as what I inquire from UDDI.
Marsh: different customers have different requirements for equivalence. Is AM equality an adequate definition of equivalence?
Marsh: RESOLVED that AM equality is adequate as a definition of equality (includes name equality). We can add a note to the spec that two portTypes (for example) with the same structure and different names are not equivalent.
[23] http://lists.w3.org/Archives/Public/www-ws-desc/2002Oct/0151.html
10:20 Break
-------------------------------------------------------
10:50 Promoting operations to the top level (Gudge)
- issue-operation-name-uniqueness [10]
Gudge walks through his proposal [10a]
Gudge: <operation> is moved to top level to simplify portType inheritence. If <operation> is a child of <portType> then we can get name conflicts. Moving <operation> to top level forces their names to be unique QNames.
Jeffsch: we agreed operation name conflict was a problem, but we did not agree that moving operation to the top level was the solution
Gudge: this is just a proposal to show people what it would look like
[JacekK: is it explained anywhere why we want to make operations sharable between portTypes?]
[GlenD: Jacek: because you can have "A implements B, C"]
[youenn: I agree, I do not clearly see the implications]
[GlenD: That's the only real reason]
Gudge: changes to <binding> are not yet done
plh: do we still need portType?
Gudge: yes, the concept of portType has not changed
JacekK: two reasons for this change are possible: 1) make operations sharable, 2) operations named the same in different portType are the same
Gudge: if A and B have operation foo and C extends A and B then foo better be the same since we no longer have operator overloading
jeffm: this is the same as resolving operations in multiple inheritance in programming languages. Moving operations to the top level is not the right way.
GlenD: the alternative is to required structural equivalence of the operations
Arthur: making the operations top level means you only need to define them in one place
GlenD: that makes the syntax more awkward
Marsh: do we want to reject this proposal and adopt the structural equivalence solution. We all agree to discard the top-level-operation approach and instead use structural equivalence (based on the AM).
summary: if an operation inherits two operations that have the same local name then their components models must be identical
[10] http://www.w3.org/2002/ws/desc/2/06/issues.html#xissue-operation-name-uniqueness
[10a] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.toplevelops.xml
---------------------------------------------------------------------
issue-fault-name-uniqueness [11]
Marsh: fault names are currently not unique with a portType
Paco: it is desirable to have a common fault handler for all operations of a portType
Roberto: faults currently can specify the message contents but not the fault code. This is a deficiency of WSDL
Paco: give faults a QName. Faults are referenced in orchestration, e.g BPEL
Gudge: given that we don't want to make operation top-level, it seems strange to make faults top level
Arthur: faults are top level in programming languages, they are more like portTypes than operations
Roberto: faults could be defined as children of <portType> rather than <operation>
JacekK: faults are messages, so why do we need another name for them?
Paco: the name of the fault is significant, not just the type of its content
GlenD; need to clarify how faults are bound
Gudge: you can define schema elements for all the faults you need. We can use schema QNames to identify faults, don't need WSDL QNames
ACTION: Paco will write two options for naming faults: schema vs WSDL.
[11] http://www.w3.org/2002/ws/desc/2/06/issues.html#xissue-fault-name-uniqueness
---------------------------------------------------------------------
12:00 Lunch
---------------------------------------------------------------------
13:00 Replacing wsdl:message with XML Schema [24] (Roberto, Jeffrey, Gudge)
Scribe: Jacek
Roberto presents his proposal [24a]
Example of message use today:
<message name="foo">
<part name="a" type="xsd:int"/>
<part name="b" type="xsd:string"/>
</message>
<operation name="differentName">
<input message="foo"/>
</operation>
<binding>
<operation name="differentName">
<input><soap:body style="rpc" namespace="ns"/></input>
</operation>
</binding>
<!-- describes a message that looks like this: -->
<soap:body>
<ns:differentName>
<a>5</a>
<b>Stringy</b>
</ns:differentName>
</soap:body>
Example of Roberto's proposal:
<complexType name="foo">
<sequence>
<element name="a" type="xsd:int"/>
<element name="b" type="xsd:string"/>
</sequence>
</complexType>
<operation name="differentName">
<input type="foo"/>
</operation>
<binding>
<operation name="differentName">
<input><soap:body style="rpc" namespace="ns"/></input>
</operation>
</binding>
<!-- describes a message that looks like this: -->
<soap:body>
<a>5</a>
<b>Stringy</b>
</soap:body>
Roberto: many messages are artificial already. Messages are not extensible.
GlenD: we cannot live with type only, we need element name, too
Roberto: I'm just showing how we can remove messages without side effects, we can decide if we do it
[Gudge: <xs:complexType name='Foo' >
<xs:sequence>
<xs:element name='bar' />
<xs:element name='baz' />
</xs:sequence>
</xs:complexType>]
[Gudge: Given the type foo, if we have:
<wsdl:input type='foo' />
What does soap:Body look like? Is it:
<soap:Body>
<somewrapper>
<bar/>
<baz/>
</somewrapper>
</soap:Body>
?? Or is it:
<soap:Body>
<bar/>
<baz/>
</soap:Body>
??]
[alewis: Gudge: If you introduce <somewrapper>, then you can't *ever* have bodies with multiple children, can you?]
[Gudge: That would be my guess, yes. We could also allow <wsdl:input group='quux' />. Where quux is a named model group with the above sequence in it.]
[alewis: Gudge: I don't see why we should introduce *any* schema-enhancement constructs inside WSDL, when there isn't anything that can't be done in a schema language.]
[Gudge: so my gut feeling is that type='foo' works as in the latter case above, and if you only want one element, you define a type that only has a single element decl/ref.]
Discussion about the impact of other type systems in light of the proposal
Paco: you still have to pack the real parts together
[alewis: Gudge: I'd agree. If you want a wrapper, wrap it.]
[Joyce: Gudge: I think it depends on the style. Rpc v.s. document]
[Gudge: Hmmm, I remain unconvinced about the difference...]
[alewis: Joyce: I'd like to object to that. I don't think that the RPC encoding hack of introducing an ambiguously named top-level wrapper element was *ever* a good idea.]
[Joyce: Amy: no, that's how people use it today]
Roberto: with messages, we are inventing a very simple additional type system
[alewis: Joyce: I know that. I just don't think it helps interop.]
[Gudge: I think that you can take what we call doc/literal today and easily map it to an RPC call.]
[alewis: Joyce: and it's possible to create the top-level elements explicitly, instead of having different toolkits assign different names (which they currently do).]
[kevinL: I agree with Amy, this needs to be improved]
[Joyce: Amy: WS-I are already dealing with the style issue. We are not making things worse.]
[Gudge: It's impossible to look at a message on the wire and determine by inspection whether it's doc/lit or rpc/lit]
[alewis: Joyce: But we could make it better. It's *definitely* in our scope, I think.]
[jeffsch: (The same is not true of */encoded, but we've already seen the light on that one.)]
Paco: message parts have a simple semantics independent of type systems
Paco: parts represent arguments of an invocation with whatever type system is actually used
[Joyce: Amy: yes, we can make things better, but rpc is the model exists over there, and we can't just drop it.]
Gudge: bindings could handle XML Schema in various ways
GlenD: we want to promote interoperability
[alewis: Joyce: I'm not proposing to drop RPC. I'm proposing that we define it in a way that is more interoperable than it currently is, by making the names of top-level elements *explicit*, not randomly chosen by the toolkit.]
[jeffsch: +1 alewis]
sgg: what about the headers?
Gudge: resolved at the last f2f
[jeffsch: Headers already refer to type or element]
Joyce: I'm concerned about RPC situation
GlenD: we'd only present the mapping for RPC with XML Schema, anyone can do other mappings
Gudge: WS-I want optional parameters, with messages and with XML Schema that could be doable easily
sgg: we do optional with xs:nillable
Gudge: in RPC, the parts refer to type which cannot be nillable
Jacek: My concern is similar to Joyce's. Are we modeling on the granularity of messages? Or are we modelling RPC style invocations? In which case we need parameters. That would practically remove the option of multiple type systems, because no one would do it.
Gudge: You could have another attribute on input, output or fault that refers to a different type system.
Jacek: But if we have an RPC style that is nillable, we are creating a subset of XML schema.
Paco: it's not just RPC, it's also attachments that use parts
Joyce: could we allow multiple types for input? (same for output etc.)
Joyce: this would remove the artificial wrapper type or element grouping the elements
Gudge: when I look at a method definition, I see two structures
[Gudge: void Foo ( [in] int i, [in] long l, [out] float* f );
struct FooIn { int i; long l; }
string FooOut { float f; }
void Foo ( [in] struct FooIn inparams, [out] struct FooOut* outparams )]
[Gudge: on the wire AND the stack frame for the two method sigs are EXACLTY the same in NDR and XDR]
Roberto: XML Schema is more powerful than our message construct
[Gudge: s/string FooOut/struct FooOut]
Paco: if we inline the concept in WSLD (if we keep message) it seems simpler
Roberto: disagree that it's simpler
[sgg: Gudge: NDR and XDR are acronyms for what?]
Arthur: in RPC, the operation name defines the wrapper element
Allen: RPC may be binding-level construct, it may not need message
[alewis: In RPC, the operation name defines an array of possible wrapper element names, one of which a toolkit will choose. Other toolkits have to know which possible names (operation, operationRequest, operationResponse, at minimum) other toolkits may use, in order to find the correct operation.]
GlenD tries to show some examples on which we can discuss stuff
GlenD goes deeper, into the binding level
GlenD: does the literal/rpc distinction go away if we do this?
[jeffsch: It might not be needed]
GlenD: until we introduce multiple type systems, it's not much different
it seems we have problems with document/rpc nuances
[jeffsch: Arthur asks how one would do this for HTTP GET (non SOAP)? Glen suggested it would be just about the same way it was done with message/part.]
GlenD: http GET binding would work because the binding would specify the interpretation of XML Schema
???: the distinction between message and complex type here doesn't go on the wire, right?
[Joyce: We get rid of the artifical construct plus it's rpc friendly.]
[Arthur: an intermediate position is dump <message> but inline <part>, e.g.]
Paco: we need to see the gain of removing message because people are already used to it
[alewis: Joyce: but you're still using WSDL as a schema language, it seems to me. And it's a much less powerful schema language than any other one that exists.]
Arthur's proposal:
<operation name="differentName">
<input>
<part name="a" type="xsd:int"/>
<part name="b" type="xsd:string"/>
</input>
</operation>
Paco: in IDL, even if you look at the invocations as two structs, it is not written as such for a reason of clarity
[Joyce: Amy: you still can do the Roberto/Gudge proposal. With one <type> under <input>.]
[JacekK: JacekK has changed the topic to: the trout has been excessively flooded.]
Arthur: the instance looses the schema information
[alewis: Joyce: then the @name attribute is a QName pointing at the schema information?]
others: you can create the schema from the WSDL
Arthur: I'm not allowed to interpret the message without reference to the WSDL which describes it
[Joyce: Amy: I'd think so.]
s/Arthur:/Jeff:/
[alewis: Joyce: Sounds the same as Arthur's inlined <part>, except that instead of <part element= type=>, you'd use <element name=> and <type name=>.]
s/Jeff/JeffM/d
[Joyce: Amy: thanks. That's the same idea.]
[Joyce: Arthur: I like the inline <part> idea and syntax.]
...discussion on wrapper elements...
[alewis: Joyce: I think that your proposal might be clearer, although it might have more issues for alternate schema languages. The definition of part says that either type or element must exist, and both can't. It's hard to explain that to people.]
...discussion on typing...
Gudge: xs:group is better than xs:complexType
[Joyce: Amy: Thanks! Therefore, Arthur and I should both present to the group -- as soon as they are done with the wrapper discussion right now. :-)]
Gudge: xs:group does not support attributes so that rids us of one problem
Example using groups instead of types:
<group name="foo">
<sequence>
<element name="a" type="xsd:int"/>
<element name="b" type="xsd:string"/>
</sequence>
</group>
<operation name="differentName">
<input thing="foo"/>
</operation>
<binding>
<operation name="differentName">
<input><soap:body style="rpc" namespace="ns"/></input>
</operation>
</binding>
<!-- describes a message that looks like this: -->
<soap:body>
<a>5</a>
<b>Stringy</b>
</soap:body>
GlenD: let's move to the example with different type systems
Example of mixing XML and MIME types:
<message name="foo">
<part name="attach" mime:type="mime:graphic"/>
<part name="param" type="xsd:string"/>
</message>
----------------
<complexType name="foo">
<sequence>
<element name="attach" type="xsd:base64Binary" mime:type="mime:graphic"/>
<element name="param" type="xsd:string"/>
</sequence>
</complexType>
<soap:body>
<attach/>
<param>String string</param>
</soap:body>
JacekK: so the instances won't validate again?
Gudge: the element can be there, but empty
JacekK: this is ugly because we are doing tricks for the XML to validate
Roberto: we're doing tricks today already in the mime binding
Roberto: what if we want array of images?
Joyce's proposal:
<operation name="differentName">
<input>
<element name="a"/>
<element name="b"/>
<type name="tns:c"/>
</input>
</operation>
if you take Roberto/Gudge proposal, you do --
<operation name="differentName">
<input>
<type name="tns:myMegaWrapper"/>
</input>
</operation>
JacekK: This boils down to what our requirements are on the complexity of invocation signature
Arthur: our (mine and Paco's) conclusion is that message is unnecessary but parts are good, so we'd like to inline parts in input/output/fault components
Arthur: we don't think it's worth naming a message
[JacekK: I think it's worth naming a message because of reuse]
[sgg: the inline-part approach makes operation equivalence harder to compute (per our operations discussion earlier)]
Roberto: it does not address shortcomings of message, does it?
Paco: messages don't seem to have first-class relevance
Arthur: with types instead of messages, you are forced to introduce a type that has no reality
Joyce: I'd propose just putting the elements or types in input/output/fault
Joyce: this still captures the idea of message parts
Roberto: you still have the implied message component
JacekK: I think we are putting too big requirements on messages
jeffsch: is the semantics of a message the same as xs:sequence minoccurs=maxoccurs=1?
others: yes
igors: how does a message represent an unbounded array of image parts?
Arthur: one mime/multipart part
JacekK: attachments may but need not be referenced from other parts, particularly the XML parts
GlenD: these issues may affect the RPC/document difference
Marsh: we have three options: leave the status quo, inline messages or ditch them
[plh-home: Arthur proposal: <operation name='foo'><input><part/>+</></>]
...discussion on details of the options...
[plh-home: Joyce proposal: <operation name='foo'><input><element/>*<type/>*</></>]
[plh-home: Roberto/Gudge proposal: <operation name='foo'><input><type/>*</></>]
Arthur: do we want to break out the parts in portType or in binding?
[Roberto: Roberto/Gudge proposal: <operation name='foo'><input type='ns:bar'/></operation>]
[Roberto: just one 'type' attribute (or an 'element' attribute, or...)]
Arthur: if we don't think of messages as homogeneous, we can ditch message construct and follow roberto's proposal
Arthur: maybe it could be phrased: should messages have parts?
[Roberto: a fixed, predetermined list of named parts]
Arhur: with atomic messages we'd defer the complexity in bindings
GlenD: the reason for Roberto's proposal can be the fact that w3c already has a thing for describing structured things
JacekK: by moving the complexity to bindings and XML Schema, aren't we introducing too much complexity?
Gudge: group only adds choice and all to the current sequence
Marsh: so do we have type, element *and* group?
Gudge: let's have just group
Arthur: so you'd have to define groups for everything?
Gudge: instead of messages, yes.
JacekK: so we'd be replacing the message construct with the XML Schema construct, parts with elements
Arthur: and you have to define how to embed mime types
...TAG concerns discussion...
JacekK and Gudge discussed XML Schema extensibility and validation
Marsh: we still have the three options listed above
Marsh: let's take a quick strawpoll to see how much support we have for the options, then take a break
Straw Poll:
Option 1: Roberto's proposal (7 votes)
Option 2: status quo (1 vote)
Option 3: inlining message construct (9 votes)
[24] http://lists.w3.org/Archives/Public/www-ws-desc/2002Nov/0035.html
[24a] http://lists.w3.org/Archives/Public/www-ws-desc/2002Nov/att-0035/01-nomoremessages.html
---------------------------------------------------------------------
15:05 Break
15:30 Type system issues (continued)
...discussion about 1.2 vs. 2.0...
Marsh: the w3c process is consensus-based so we may want to reopen some issues that we've closed before
back to the issue of what we do with the message construct...
Arthur: the message inlining proposal is just a syntactic cleanup, really
sgg: let's also pay attention to how operation equivalence is affected
ACTION: Roberto will try and come up with another proposal, the discussion goes to email or the next f2f
---------------------------------------------------------------------
issue-allow-nonxml-typesystems [26],
This issue seems to be obsolete.
It is already on the editors' todo list to clarify that we do support non-xml-schema type languages
we believe that it is general enough to allow non-xml type systems.
Nobody objects to closing the issue by allowing non-XML type systems.
[26] http://www.w3.org/2002/ws/desc/2/06/issues.html#xissue-allow-nonxml-typesystems
---------------------------------------------------------------------
Rationale for dropping the <soap:body use=...> attribute [27]
Proposal from Jacek on better describing the extensibility
mechanism to support other languages. [28]
JacekK: my concern was about allowing other type systems, that concern's was gone
Marsh: we wanted to first warn the public that we might be removing the use attribute
[jeffsch: http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0065.html]
GlenD: what about using SOAP Encoding?
Arthur explains reader-makes-right and writer-makes-right
JacekK: do we want to just describe the interfaces or do we want to allow validation, too?
JacekK: if we want to allow validation, we need to be literal (we can drop use=...), in which case SOAP Data Model schema might have to be necessary
we can create the situation where WSDL depreciates a part of SOAP
Glen: can we bring this to the XMLP WG?
JacekK: could we include in WSDL the SOAP Data Model Schema language?
ACTION: Marsh to contact the XMLP WG (and later the wider public) speaking about the issues around removing the use attribute.
[27] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0054.html
[28] http://lists.w3.org/Archives/Public/www-ws-desc/2002Oct/0040.html
---------------------------------------------------------------------
issue-clarify-type-and-element [29],
Do we want to remove the element (or type) schema accessors from WSDL?
This issue depends on the issue about handling the message construct
Posponed for later
[29] http://www.w3.org/2002/ws/desc/2/06/issues.html#xissue-clarify-type-and-element
---------------------------------------------------------------------
Extension using substitution groups [30]
Marsh: our open-content model doesn't really allows us to validate the interaction of an extension and WSDL
Gudge explains his proposal: we'll create abstract elements in extensibility places
flip side: element can only be in one substitution group
possible solution: we'd create all the (necessary) combinations
solution: one for everywhere, other practical combinations
...discussion about XML Schema understanding...
[tomj: I think Gudge knows what he is doing and his changes sound very good.]
[tomj: I have some small concern about enumerating all of the combinations]
...discussion on how this would actually be done...
...slapping with a large trout going on about XML Schema insults...
ACTION: gudge to ammend WSDL schema to use substitution groups for extensibility rather than wild cards.
[30] http://lists.w3.org/Archives/Public/www-ws-desc/2002Oct/0089.html
---------------------------------------------------------------------
issue-remove-optional-name-of-definition [31]
Should we remove the optional name attribute of <definitions>?
TomJ raised his comment that at least one person seemed to the attribute was a good thing
DECISION: no objections to removing the attribute
[31] http://www.w3.org/2002/ws/desc/2/06/issues.html#xissue-remove-optional-name-of-definition
---------------------------------------------------------------------
issue-implements-attribute [32]
Should there be an implements attribute on 'service'
tomj: does that attribute reference a porttype?
jeffsch: component model makes clear the value of the portTypes property of service. The question is if we want to add a redundant serialization of this property.
Joyce: what about portTypes implemented multiple times (via multiple ports)?
Paco: it's only present there once in the attribute
GlenD: what's the value of one service with two ports with different bindings of different portTypes
Glen's question deemed off-topic
Paco: this may be related to the serviceType thinking
[alewis: Question: how are inconsistencies to be handled? What if implements indicates a superset, rather than a subset? Which is the canonical part, and if the non-canonical has to be verified, why is it useful?]
[jeffsch: +1 to alewis]
JacekK: the attribute would be an optimization
[jeffsch: does anyone understand the UDDI issues here? does one way make it easier / harder for UDDI given their best practices for WSDL? [32a]]
Gudge: and unreliable, too
Marsh: is this solving a real performance problem?
Marsh: can this be solved using extensibility?
tomj: it does sound like the attribute might be nice, is the only objection that the attribute is redundant?
[jeffsch: It looks like the UDDI best practice doesn't use wsdl:service and starts with wsdl:binding.]
[alewis: The problem isn't that the information isn't interesting. The problem is that either service/@implements is canonical, or service/port/@binding -> binding/@type is canonical.]
[jeffsch: My conclusion is that a service/@implements attribute wouldn't be used by this web service search technology (nor does it need it)]
[alewis: If these aren't in synch, what are you going to do?]
...more discussion on the usability and value of the new attribute...
tomj: not everybody has to check for inconsistencies
JacekK suggests to resolve this by pointing to extensibility and do nothing else
jeffsch: are some people suggesting that some WSDL processors could accept information from WSDL documents that would be rightly rejected by other WSDL processors?
GlenD: it happens all the time with everything
[tomj: Tom: Feels that this is one place where we can make WSDL easier to use from both a tool and human point of view]
Paco: this redundancy could help catch some errors in WSDL files - a service's author wanted something that's no more true
Gudge: originally, we wanted a service to implement a single portType
[alewis: Sounds like service/port ought to be removed, and all of its content moved down into service.]
[Gudge: amy: I don't understand your statement...]
[Gudge: port already appears inside service]
[alewis: Gudge: The only reason I can think of to have port inside service is so you can have more than one, each pointing in a different direction.]
[alewis: Gudge: So, if you wanna have one service == one portType/binding (one address, implicitly), then you don't need multiple ports in a service.]
[jeffsch: Discussion of single portType per service at http://lists.w3.org/Archives/Public/www-ws-desc/2002Oct/0028.html]
...revisiting the issue whether one service should be only doing one portType...
http://lists.w3.org/Archives/Public/www-ws-desc/2002Oct/0028.html
Marsh: does anybody want to reopen the issue?
GlenD does, sees a lot of value in services implementing one aggregate portType
Strawpoll: do we want to pursue the attribute?
yes: 3
no: 11
Issue is closed untill we agree to reopen the question of services implementing a single portType.
ACTION: Glen and Paco to chase the Global Grid Forum WRT services implementing a single portType.
[32] http://www.w3.org/2002/ws/desc/2/06/issues.html#xissue-implements-attribute
[32a] http://www.uddi.org/pubs/wsdlbestpractices-V1.07-Open-20020521.pdf
17:30 Adjourn
Raw IRC log: See http://www.w3.org/2002/11/12-ws-desc-irc
Received on Friday, 15 November 2002 13:03:35 UTC