- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Fri, 24 Jan 2003 11:42:47 -0800
- To: <www-ws-desc@w3.org>
-------------------------------------------------------
Tuesday 21 January
-------------------------------------------------------
Present:
Erik Ackerman Lexmark
David Booth W3C
Allen Brookes Rogue Wave Software
Roberto Chinnici Sun Microsystems
Youenn Fablet Canon
Steve Graham Global Grid Forum
Martin Gudgin Microsoft
Tom Jordahl Macromedia
Philippe Le Hégaret W3C
Steve Lind AT&T
Kevin Canyang Liu SAP
Michael Mahan Nokia
Jonathan Marsh Chair (Microsoft)
Jeff Mischkinsky Oracle
Dale Moberg Cyclone Commerce
Don Mullen Tibco
Arthur Ryman IBM
Jeffrey Schlimmer Microsoft
Igor Sedukhin Computer Associates
William Vambenepe Hewlett-Packard
Steven White SeeBeyond
Umit Yalcinalp Oracle
Prasad Yendluri webMethods, Inc.
Observers:
Martin Duerst I18N
Phone:
Amelia Lewis TIBCO
[Jeffsch scribes]
-------------------------------------------------------
09:00 PortType operation name conflicts [5; part b].
[5] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0004.html
Steve: Grid expecting >> port types with >> operations. Expect
these to be mixed together through port type composition.
Believe that current design for operation naming constrains
this. For example, Port Type 1 and 2 both define an
operation with the same name with a single message that has
a different XML Schema type. Per the spec today, it would
be illegal for a third port type to inherit from both of
these. The implication is that GRID would have to coordinate
operation names across all of their operations.
Gudge: Per spec today, if you have two operations with the same name
property, then they must have all the same other properties.
There is a potential (if unlikely) danger that there would be
two identical operations that had different semantics. Keep
in mind that the operations actually refer to typed messages.
Jonathan: Is this an overloading problem, or is there something more to
this?
Tom: Note that operation overloading won't solve the problem of an
implementation having only one piece of code to process a
given message. We previously decided not to do operation
overloading for this and related problems (though "modern"
languages do have overloading).
Roberto: Not all "modern" languages have the same model for
overloading. Java allows interface inheritance; if the
signatures of two methods are different, then the method is
overloaded.
Gudge: Could make operations QNames, which is simple in the component
model, but there were some concerns re: syntax at the last
face-to-face. At the component model, to allow overloading
operations, we would have collapse (as today) if all the
properties of the operation (name, messages, MEP) but not if
any were different.
Roberto: Couldn't we leave the syntax as it is today, i.e., leave the
operations nested within the port type even if we decided to
give them top-level names? To avoid the GRID problem, they
would use different target namespaces.
Gudge: The uniqueness constraints would be the same as for other
global names.
Arthur: Today we allow different port types to have operations with
the same name, and this is useful in expressing multiple
classes as multiple port types in the same namespace.
Gudge: Could never collapse operations when inheriting by defining
the name of each operation to be a concatenation of the port
type name and the operation name. In this option, think of
the port type name as a sub namespace, where the full name
of the operation would be the target namespace plus the port
type name plus the operation name. You could still collapse
at the implementation level but not at the operation level.
Arthur: In the diamond inheritance case, where a single port type is
inherited > 1 time, then operations it defines would still
occur.
Steve: Would this violate any encapsulation requirements?
Arthur: Think of all the operation names as public.
Gudge: Though the port types leak into the operation names...
Jonathan: Does this work in the face of the open content model?
Steve: Yes. The names of the operations are different by
construction, and that was the point of conflict.
Tom: How does this affect the wire representation of these
operations?
Gudge: You would have to provide > 1 namespaces. We could turn the
port type into a URI and use that for the namespace.
Jonathan: (The TAG is considering how to do this.)
Tom: Concern re: complex processing rules and implications for
how bindings and wire formats look.
Gudge: Steve's use case requires a way to make the operation name
unique. We could provide a means in the derived port type
to reference / rename either or both of the conflicting
operations? Remember that the operation name doesn't
necessarily appear on the wire.
Martin: How would we distinguish between two messages which have
the same wire format?
Gudge: If they look the same on the wire, then they _are_ the
same message, and they collapse.
Tom: If we fix this in the WSDL component model, won't the
implementation of the derived port type have difficulty
distinguishing between the two intended operations?
Jeff: They do have a workaround. They can come up with a naming
convention for operations, for example, port type name,
underscore, and operation name concatenated together.
Gudge: (reiterating) The key issue is to make the operation names
unique.
(Scribe notes digression into RPC versus document literal...)
Steve: Is there a requirement on the component model that
operation names be unique?
Gudge: Currently, they must be unique within a port type, and
2.5.1 says that operation names given inheritance must also
be.
David: This looks important enough to be addressed.
Jonathan: Show of hands for how many people feel we can live with
what we have today? (1 raised)
Gudge: Summarizing options.
1 Introduce operator overloading
2 Make operation names QNames
3 Operation names are scoped by target namespace and port
type names.
4 Rename operations within derived port type
We don't have much understanding of some of these options
(e.g., 3 and 4).
Steve: Are there ongoing concerns re: syntax of 2?
Tom: QName for operation would simplify RPC style because it is
the complete value to put on the wire (don't have to grub
about to find the namespace).
Gudge: Arthur pointed out a use case where this would be awkward.
Consider backward compatibility case where a Web Service is
running and described in WSDL 1.1. When converting to WSDL
1.2, the conversion would fail, yes?
Roberto: Why not put uniqueness constraint on the port type, allowing
two operations to have the same QName as long as they are
not used within the same (potentially) derived port type?
Steve: How would the developer of the derived type resolve the
latent conflict in naming of operations in inherited port
types?
Gudge: This should address Arthur's concern because it would be OK
to have two operations with the same QName as long as they
are used within the same port type.
Tom: Can we eliminate the namespace attribute given that
operations have QNames. The wrapper name would be the QName
of the operation.
Jonathan: Let's review the proposal in detail:
2a Add namespace property to the component model of the
operation
2b Modify uniqueness constraint to say that combination
of name and namespace must be unique within a port
type. Equivalence of two operations would be defined
based on structure (even though they have QNames)
because duplicates are allowed.
2c Investigate removing namespace attribute from the SOAP
binding
2d Add a best practice note to explain why giving two
operations (in different port types) the same name and
namespace is not best practice.
Gudge: Note it might be misleading to use the term "QName" to refer
to operations that have a name and namespace properties
because they cannot be referenced (they are not globally
unique). May refer to these as name and namespace pair in
the spec. 2a += Add a namespace property to the binding
operation.
Steve: How would bindings work?
Gudge: In the current spec, one writes a binding against the
transitive closure of the operations inherited.
ACTION: Gudge write up proposal for operation naming by next week.
-------------------------------------------------------
10:00 Removing message. Roberto's original proposal at [7].
Direction suggested by Dale [8]. Roberto will provide an outline
for the discussion [8a]. Sanjiva's proposal [8b].
[7] http://lists.w3.org/Archives/Public/www-ws-desc/2002Nov/0035.html
[8] http://lists.w3.org/Archives/Public/www-ws-desc/2002Dec/0040.html
[8a] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0066.html
[8b] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/att-0042/01-remove-message-jan-18-2003.html
Roberto summarizes his post (URL [8a] above).
-------------------------------------------------------
10:30 Break
-------------------------------------------------------
Removing message, cont.
Jeffsch: +1 to the issues Roberto is address
Dale: +1 to Sanjiva proposal
Gudge: Concern re: introducing cardinality within operation
Prasad: Value of cardinality for use case like number of items in
a purchase order.
Arthur: We are re-inventing because we want to treat MIME types as
first-class.
Roberto: We could consider MIME as a type system with its own
definition of repetition of parts. Instead you're
proposing a third type system, of our own invention.
Umit: Value in neutral type system, that wraps others, providing
a consistent "interface" across others for the rest of WSDL
to reference.
Roberto: Concern about defining a third type system.
Arthur: Can we cover the 80% of the cases.
Umit: Sanjiva proposal allows retaining partial evaluation (?)
and enumerating parts to allow repetition. Eliminates message
construct while retaining parts.
Dale: See value in separating the message from port type interface.
MEP could talk about pattern of exchanging, and subsequent
binding could map into different packaging schemes.
Roberto: The multiple inputs are essentially defining a type. Why don't
they appear in the types section? There are issues in creating
a new language. Why?
Arthur: Parts are a useful concept, and it is convenient at binding
time. If you don't have parts, you need something like XPath
to pull out what goes where in a specific binding.
Roberto: That argument plays the other way too. (Missed the clever
argument.)
Gudge: Syntactically, one would refer to message/part in the same
way that you'd refer to children within a type (like Schema).
Dale: Do you want complex types rolling up things like image/jpeg?
Gudge: I strongly believe we need to get to a strong Infoset view
or we're going to be in serious trouble in the long term.
Specifically, I agree that there needs to be something in
the Envelope that indicates the MIME type of the content.
Jonathan: Concerned about attachments as a requirement at this point
because the W3C XMLP (SOAP) WG is still collecting
requirements for attachments.
Arthur: Are you saying that all procedures should have one argument
that is a structure?
Gudge: No.
void Foo ( int i, int j )
struct { int i, int j )
void Foo ( struct A )
These look the same on the wire (and incidentally, on the
stack frame).
Arthur: (Picks nit about whether it's the same on the stack frame.)
One could argue that we don't need multiple arguments
because one argument would be sufficient? (Implicitly doesn't
agree.)
[<Arthur> Rebutting a false assertion is not nit picking.
* jeffsch apologizes -- the single stack thing seemed off topic. Bracing
myself for the trout slap...
* TomJ slaps jeffsch around a bit with a large trout.
<Arthur> yes, maybe Gudge can explaing the relevance of the stack
discussion.
<Gudge> my real point was about the wire. The stack observation was a
side point. In C/C++ the stack is the same. In C# it's also
the same. Java doesn't have structs ( AFAIR ).
<Arthur> Java has only pass by reference, C/C++ has both pass by value
and pass by ref. So even in C/C++ you can pass a struct by ref.
<Gudge> I understand that, as I said, the stack thing was a side issue.
My main point was that just because you describe the wire in
terms of a structured type doesn't mean you have to have a
method that takes that structured type as its single parameter.
<kevinL> Agree with gudge.
<umit> If the structured type on the wire needs to be mapped to a method
differently, you would still need unambigous mapping which has to
work both ways, extracting from the message and composing from the
method call.
<Arthur> I also agree with Gudge. My point is that multiple args to a
method is useful, and so are multiple parts in an operation.
<umit> See the note we sent last night.
http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0067.html
]
Gudge: Drawing an analogy to multiple operations per port type,
we _could_ have just one operation per port type, but the MEP
would become unweildy.
Umit: If you have a single part, you can already use XML Schema as
desired. (Implictly suggesting value for multiple parts.)
(Discussion about programming language model versus describing messages
on the wire.)
Roberto: Doesn't agree that because programming languages have > 1
parameter therefore WSDL message description (whatever it is)
must have multiple parts.
Tom: Starting to doubt the wisdom of cutting wsdl:message but
would like to make improvements. See value in removing
message construct and keeping parts.
Roberto: At a finer-grain, would like to keep the syntax within the
operation for referring to direction (and maybe sequence and
cardinality) over messages as a whole.
Roberto: Writes up an example based on WSDL 1.1 example.
Roberto: Writes up an example based on XML Schema ( similar to previous
proposal from roberto/jeffsch/gudge )
Roberto: Writes up an example based on SW proposal.
Roberto: (Re)writes Sanjiva proposal
Roberto: Reviewing criteria:
- 1 Similarity to WSDL 1.1:
A (WSDL 1.1) is best
B (earlier Roberto proposal) natural for people who think
about types,
C (Sanjiva proposal) natural for people who think about
parts.
Kevin: If operation points directly to the type system, would it be a
complexType?
Roberto: We discussed model groups (to restrict attributes, for one
reason)
Jonathan: Does Sanjiva's type indicator commit to complexType or Element?
Prasad: No.
Roberto: 2 Readability
Jeff: Does new Sanjiva proposal allow reusability of messages?
Arthur: Not clear that messages are, in fact, reused in practice when
WSDL is generated from code. May see some message reusability
when WSDL is written by hand. Mostly an authoring concern.
May be some benefit if one is trying to determine if two
messages are semantically equivalent.
Igor: The Sanjiva construct doesn't work with the MEP decision
(from yesterday).
Jonathan: Does start to beg for a wrapper to define message boundaries.
Arthur: Modification of the syntax is not a difficult issue.
Jeff: There are two things in SW prop. 1. Let's not have message be
top-level, let's in-line it. 2. Enhancing the message
construct by making it more expressiveness. So that we could
do things like say that a part was optional. Thinks there is
a deep seated desire from some people to have first class
notion of parts.
Umit: At the moment the parts are a sequence. I could map a
sequence of elements in XML Schema to parts in a message.
But other schema constructs ( like xs:all ) create problems
Jeff: (to umit) So your concern is that XML Schema is TOO expressive
and it would complicate bindings
[<Arthur> message parts are atomic wrt binding]
Umit: Not exactly, i'm saying we have the expressive power today.
Jeff: Confused by your argument
Umit: The mapping from complex type in the schema world, is much
more complicated for the binding.
[<Arthur> message parts are the things you bind]
Don: You might have to restrict the schema bits you use if you
actually care about parts.
Umit: How do you bind ( for example ) xs:all?
[<kevinL> it's more an issue of best practice. the xsd author needs to
take it into consideration if sequence of elements are critical.]
Umit: Why don't we remove operation too?
Roberto: For example, operations provide a boundary around MEPs.
The reference within the operation points to a type in XSD, but
one could reference a type within a MIME type system too.
MIME could be used as the overall type system, if you like.
Tom: Someone would have to invent such a language...
Roberto: There's something there in WSDL 1.1, and if people cared, we
could easily take the MIME multipart binding and make it into
a type system.
Jeff: There already is a MIME type system, it's just not very well
defined. (And I don't know if anyone cares enough to do so...)
David: Is the point of the message construct to associate messages
with a MEP?
Roberto: Yes
Prasad: Why do you prefer putting an attribute on a type definition
rather than on an element?
Roberto: More correct use of Schema but could do either.
Kevin: An attribute on a complex type would allow doing a choice over
image/jpeg and image/gif.
Roberto: 3 Simplicitly / consistency for advanced users
B (type system approach) gets rid of separate operation construct
and rference component. Component model in A (WSDL 1.1)
Don: Does the binding component model get more or less complex with a
type system approach?
Gudge: Not sure the binding can remain independent of the type system
description.
Umit: Experience writing a programming language binding suggests that
the wire binding for the type-system approach will be difficult.
JeffM: Can we move forward with the type-system approach if we don't
have confidence about the feasibility of the wire binding?
Roberto: Some small fraction of people are using sophisticated type
descriptions today, and they would continue to do so. Others
who are doing simpler things would continue to do simple things.
Arthur: If our specs say XML Schema then compliant implementations will
have to implement XML Schema.
Gudge: That's already true.
Arthur: Tools may be generating sophisticated XML Schema.
Jeff: Tools may also be generating things that are more regular.
Arthur: Are we going to have to support XPath too? This would drag XML
Schema processing into the port type and binding (where it's
limited behind the message construct today).
Roberto: Do not currently prevent one, sophisticated part, and the type
system approach doesn't change that.
Tom: Should we take the leave it alone or change it straw poll?
Gudge: Depends on how you'd want to change it...
Jonathan: The in-lined message proposal isn't consistent with MEPs to
be reviewed today.
-------------------------------------------------------
12:00 Lunch
-------------------------------------------------------
[Gudge scribes]
Topic: Continued discussion on removing message
SteveW: How does removing message affect higher level languages
( like BPEL which refers to messages )
Roberto: We don't know what their requirements are. The Choreography WG
may well send us requirements.
Umit: They need to be able to add document fragments...
Arthur: Sanjiva is involved with BPEL, he wouldn't suggest something
that would break BPEL.
SteveW: Right now BPEL references message directly so it would break.
Arthur: Sanjiva will have to answer that.
Roberto: We need to see some concrete requirements. We can't really be
constrained if we don't know the requirments. We were going
to look at expressiveness. Biased as I am, I think the schema
based proposal has a greater expressive power. As jeff said
we'd already decided to avoid adding more abilities to message.
Jonathan: With schema based approach you can incrementally use features.
You can use all of schema today.
Roberto: Yes, but then you would only have one part.
Jonathan: So you are saying the more expressive features are simpler
because of the lack of a wrapper. Moving onto multiple parts
in a message.
Roberto: In status quo and SW proposal, there are constructs called
parts. In schema approach the Infoset is where the 'parts'
appear. There are no parts at the operation level. As an
advocate for B, I don't think parts are interesting in the
non-attachment case. Common use of multiple parts today is
to specify attachments.
Arthur: Parts are also useful for HTTP GET
Jeffsch: wow. We are going to have a non-SOAP HTTP binding.
Arthur: Parts are a good match to the HTTP binding.
Jeffsch: There are at least two wire bindings.
Arthur: All of these are equivalent. Which is simpler.
Jeffsch: Some of the expressiveness may not be all that useful. Prods
TomJ.
TomJ: We're already dealing with 'wrapped Doc/lit' so parts are not
critical for rpc. Pulling the bits out of the schema is just
an extra level, it's not that big a deal. The only thing
I've really heard is 'Why don't we just leave it alone'.
Various: Assertions about parts being useful for parameters as well
as attachments.
Arthur: Spec is silent on how the HTTP GET binding really works WRT
complex types. GET binding is being pushed by the WSA.
Jeffsch: Rathole about non-SOAP HTTP binding. Refresh group memory.
Whole host of requirments on HTTP GET binding mainly from
Paul Prescod. Some of these have been written up. WG was not
keen on most of them. PP assumes we are NOT trying to map
everything to every binding. We're doing the HTTP binding
because we have to, not because the WG is interested.
TomJ: So, the GET binding isn't so interesting. Are we going to
change this?
Roberto: Asks the 'who's going to lie down in the road?' question
Philippe: We'll still have to do the HTTP GET binding whatever we do.
We already know there are problems with the HTTP binding.
Jonathan: Some stuff about what arthur said earlier...
Philippe: DOrchard sent a proposal to the TAG about serializing
Infosets into URIs.
Jeffsch: The web arch guys run screaming from the ugly syntax you get.
Paul Prescod was comfortable with having simple URIs and not
being able to bind all messages.
Arthur: With GET the parameters would be part of a results. Complex
arguments would be in POST. Current non-SOAP bindings
should be one that allows you to specify the HTTP verb.
(scribe wonders if this has any bearing on getting rid of message)
Arthur: Should be able to specify the verb on a per op basis
Philippe: Language design decisions should not be based on bindings.
ACTION: Issues list maintainer to check that we have an issue
regarding being able to specify the verb on a per operation
basis.
Jeffm: Answer to roberto's question is 'It depends'. On whether
the soap binding is straigtforward, unambiguous etc
Jonathan: Is fixing the rpc issues regarding being reversible/round-
trippable, unambiguous, straightforward orthogonal to
getting rid of message?
Umit: I thought we were going to look at the binding issues and
then make a decision.
Roberto: We can't make up a binding on the fly.
Umit: How the binding works is crucial to the decision to get
rid of message.
Jeffsch: Statement of procedure: We have a proposal. Roberto is
asking for large objections. Some people are saying that
we can't answer until we know what the binding looks like.
Is that the only objection.
Dale: Many of these proposals are similar. Major question is how
does it affect binding? Seeing the bindings and a
comparison would help. Then could see which one was easier
to implement.
Roberto: I think the expressiveness argument is compelling.
Dale: Don't agree. Thinks SW proposal is just as expressive. Or
status quo is just as expressive. ecause you can have
single part messages that reference a type.
Jeffsch: You can't say that status quo/SW is as expressive as
schema approach and then also say that status quo/SW is
simpler in terms of binding.
Arthur: So we can describe equally complex messages with all
approaches.
Jeffsch: Then I reject the argument that the binding will be more
complex in any case. In all cases the binding has to deal
with arbitrary complexity. So you (Dale) are thinking about
how mime-types are addressed in a proposal that is based
around XML Schema ( or other type system ) based approach
Dale: Yes, that's one of my concerns. Jumping into defining data
types other than XML in the XML type system is not
motivating to me. I think that the complexity of doing
( for example ) multi-part mime is XML Schema is not good.
Jonathan: Don't see the complexity.
Dale: Characterize input as a xs:base64binary, but in multipart
mime it's not base64, it's binary.
Roberto: We pick a type in the schema type system that represents
binary. The BINDING tells you how it gets serialized.
Jeffsch: In the past we've been concerned with differences in the
way the message is described and the binding that is used.
In the type system proposal the coupling between the
message structure and the binding is slightly lower. Could
bind it to SOAP ( binary would get serialized as base64
text ) or SwA ( binary would get serialized as binary mime
part )
Dale: So seeing the bindings would be really useful.
Jeffsch: Need to identify all the issues ( like, need to see the
bindings ) before we invest in the work.
Prasad: So if I use this base64 ...
Roberto: Binary array in programming language, binary attachment at
the serialization level. It takes an integrated infoset
approach.
Jeffsch: You could validate it at the infoset level.
Igor: What would it look like at the Infoset level?
Gudge: It would have base64 children at the infoset level ( but
NOT at the serialization level ).
MartinD: I can imagine an image, and a digsig. can you have both
binary attachments and inline binary?
Roberto: At the binding level you would say which things are done as
'attachments' and which are done 'in-line'.
Jeffsch: Seems like apps might want to influence whether stuff gets
inlined or serialized as an 'attachment'.
MartinD: Could the binding make default assumptions?
Roberto: Yes.
Martind: Can I restrict it to image/gif, image/jpeg? Some mime
types have other parameters.
Jeffsch: If you wanted to serialize an infoset with multiple character
encoding...
Jonathan: May be some issues WRT exactly what goes in the 'media-type'
attribute?
TomJ: Let's see a binding.
Jeffsch: Not convinced that producing such a binding would help the
group.
TomJ: I want to see what the SOAP-HTTP binding looks like.
Jonathan: Current binding has 'issues'. It will be hard to compare a
new proposal with the existing binding.
[<alewis> What do we mean by "binding" at this point? The syntax
proposed? Or something else?
(how the binding would actually work?)
Tomj: I want to see how the syntax works with one or two
interesting examples.
Umit: I would want to see an example of a complex type that has
'xs:all'
Alewis: Would it be useful to ask the folks to use the same set of
examples?
Jonathan: Want to decide either - leave it alone, or we are going to
change it.
[<alewis> It's not going to happen today, I think. And it sounds as
though there is a very *specific* requirement from some
people that's needed to move forward.]
Jonathan: One thing roberto is concerned about is what the level of
interest/opposition is. It would be nice to know whether
there is interest in continuing to pursue this.
TomJ: My thinking is just leave it alone.
Dale: Agrees with TomJ.
[<alewis> I'd rather see message removed. But it's not a *critical*
issue, as far as TIBCO is concerned.]
Jeffm: Preference not to pursue it. But if we do pursue it we'd
prefer SW approach.
A is status quo
B is referencing type systems directly from operations
C is SW proposal from Jan 2003
Preference poll:
A: 3
B: 11
C: 5
Live with poll (not counting preferences):
A: 14
B: 5
C: 3
Total Live with number
A: 3 + 14 = 17
B: 11 + 5 = 16
C: 5 + 3 = 8
[Chair's summary: No clear direction, but clearly interest in pursing
this further.]
SteveG: There is an example in SW proposal.
TomJ: There is an example in the WSDL spec
ACTION: Umit to send Gudge and Roberto a knarly XML Schema type example
ACTION: Roberto and gudge to create a branch and work up a binding
proposal based on referencing type systems directly from
operation components.
Tomj: Channels Jacek. Does b support multiple type systems?
Roberto: Yes, B supports multiple type systems.
-------------------------------------------------------
13:00 Property-dependent issues. Goal is to at least have a plan of
attack for those we cannot swiftly resolve.
- BindingType proposal from Kevin [9].
- HTTP Binding Issues (6a, 41) [10, 11].
- Issue 28: transport='uri' [12]
- Issue 2: SOAPAction has been deprecated, as of SOAP 1.2
[13, 14, 15].
[9] http://lists.w3.org/Archives/Public/www-ws-desc/2002Aug/0009.html
[10] http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0102.html
[11] http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/0067.html
[12] http://www.w3.org/2002/ws/desc/2/06/issues.html#x28
[13] http://www.w3.org/2002/ws/desc/2/06/issues.html#x2
[14] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0050.html
[15] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0056.html
Postponed all these issues, given that no foundation was laid in the
Properties/Features item yesterday.
-------------------------------------------------------
15:20 Issue 25: Interaction between W3C XML Schema and SOAP Data Model
Gudge's explains at [16], Roberto's options at [17].
How do we revive this issue?
[16] http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0186.html
[17] http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/0071.html
Gudge: It's obsolete. We should drop it.
-------------------------------------------------------
15:00 Break
-------------------------------------------------------
16:00 WS-I Basic Profile [18] status, and walkthrough of the profile as
it relates to WSDL (Prasad).
[18] http://www.ws-i.org/Profiles/Basic/2002-10/BasicProfile-1.0-WGD.htm
Prasad: Wanted to show the latest draft but due to process issues we
cannot. Will try to do the best we can.
Jonathan: Document has a section on Description. Each section is a set
of requirements. Some requirements match changes we have made
( e.g. wsdl:import )
Prasad: One key deliverable is a Basic Profile, profile of SOAP 1.1,
WSDL 1.1 and UDDI 2.0. Profile provides requirements based on
interop issues with those specs. Orofile defines conformance
targets, e.g SOAP Processors, WSDL documents, SOAP messages,
and then applies requirements on those targets. E.g. you must
define your WSDL document in this particular way. Profile is
divided into sections, one for each spec. Going to look at
the requirements on WSDL 1.1. Divided into sub-sections based
on the sections of the WSDL 1.1 spec. Each requirement or
group of requirements has associated rationale text that gives
reasoning for what the interop issue was and why the
requirements were needed. Often correct and incorrect
examples are also provided. Requirements use MUST, MAY,
OPTIONAL, SHOULD etc. Each requirement is based on one
conformance target ( e.g. SOAP message or WSDL description ).
Profile in general restricts rather than relaxes the base spec.
Profile defines a subset. Sometimes offers clarifications.
WS-I BP is trying to align it's decisions on SOAP 1.1 and
WSDL 1.1 with the work being done at W3C on SOAP 1.2 and
WSDL 1.2 where possible. Requirements based on WSDL 1.2
decisions ( or SOAP 1.2 decisions ) are flagged in the document.
Example requirement: WSDL not very clear about importing WSDL
and Schemas. BP clarifies the use of wsdl:import and xs:import
(R2001 - 2004).
Jonathan: So if WS-I were to profile WSDL 1.2 would they need these
requirements? Ideally such a profile would not have any
'clarifications'. So a WSDL 1.2 profile would be subsetting
the WSDL 1.2 spec based on places we had provided optionality.
Don: Should we make notes of feedback we want to send to WS-I?
Various: Some discussion about whether schema types in an imported WSDL
are visible to the importing WSDL.
Prasad: R2005 says that targetNamespace of imported WSDL must match
namespace attribute on wsdl:import. R2007 is an example of
a mismatch between the schema for WSDL and the text of the
spec.
Jonathan: So for our spec is the schema normative or the spec?
Philippe: We can fix the schema anytime we like. Make the schema
non-normative (it's not in TR space).
Prasad: R2008 is another clarification. You don't need to follow the
location attr.
Arthur: What about same namespace imports, are they legal?
ACTION: Prasad to raise issue of same namespace imports with WS-I BP.
Prasad: R2022 another clarification of schema vs spec. R2101 is
saying you must import things before you can reference them.
R2110 - BP prohibits use of encoding, including SOAP encoding,
hence soapenc:arrayType is disallowed. Message section:
Profile makes clear statement as to when to use type vs
element in message parts. Also covers number of message parts.
Newer versions of BP doc have cleaner language in this section.
Further clarifications of messages. Port types section.
Addresses description of parts that form headers. BP allows
parameterorder.
TomJ: It is useful for codegenerators.
Jonathan: Should we define a set of code-gen hints? In another namespace?
TomJ: Would be nice to have more hints. Hints could include funtion
names, signature etc. Would help people to map into other
programming languages
Jonathan: What other hints are there?
Jeffsch: Rpc style is one kind of hint. Was wild speculation but we
could publish a note along the lines that the definitive
'thing' is the messages but hints in the WSDL could help people
Jonathan: Would be nice to have adequate set of hints.
Jeffsch: Might help with layering.
TomJ: Parameterorder was more of a pain to deal with than a helpful
hint ;-)
Prasad: Profile mandates SOAP-HTTP binding so Notification and
Solicit-Response are disallowed as that binding does not
define mapping for those operation types. Binding section:
Can only use the SOAP-HTTP binding, can't use MIME bindings
or HTTP GET/POST bindings. Might change due to recent
decision to incorporate attachments ( means fixing the WSDL
MIME bindings )
Tomj: Is WS-I going to do SwA or DIME?
Gudge: SwA
Various: Discussion of what our scope is and which attachment
technology WSDL 1.2 should support.
Jonathan: We need to think about it further. Will be gated somewhat
by the work done by XMLP.
Prasad: BP intends to fix-up the WSDL 1.1 MIME binding so that it
works with SOAP with Attachments ( SwA ).
TomJ: Does MS emit WSDL for DIME?
Jeffsch: WSE ( Web Services Enhancements ) supports DIME via
WS-Attachments.
Prasad: Ports section: empty. SOAP Binding section: Only supports
SOAP 1.1. More schema clarifications. Can't mix and match
style in a binding. All ops must be either rpc or doc.
Services can expose compliant and non-compliant ports.
Can mark WSDL descriptions as being WS-I compliant. A
<wsi:Claim/> element can appear in the wsdl:documentation
element.
[<wsi:Claim conformsTo='uri-for-basicprofile' />]
Prasad: BP says one-way messages do not have SOAP-level responses;
this is consistent with WG decision about one-way MEP
yesterday. Looks as if BP needed to clarify wording re:
when namespace is needed. More clarifications regarding
inconsistency between schema and spec. Descriptions MUST
use XML schema 1.0 and MAy use any schema construct
Jonathan: What's the rate of new issues being brought up?
Prasad: It had stabilized but with the decision to address
attachments new issues are being generated against the
WSDL MIME bindings.
Jonathan: Is the BP draft due in 2 weeks going to be a 'Last Call'
draft?
JeffM: More likely to be LC - 1. Plan is to get what we have out
and then have a 'last call' later. Let's use WS-I terms.
BP WG says 'we think we are done' and publishes a draft.
Minimum 30 day review period, change proposals can be made
and voted on up to 7 days before the end of the 30 day
period.
Philippe: Does the WG plan to respond to comments?
Jeffm: Yes. WG members can make concrete change proposals. If the
WG says, yes we approve the draft then it goes to the board.
Board reviews and votes then it goes to WS-I membership. WS-I
membership votes and spec is published. At any stage may get
sent back to WG for changes. Are trying to do a public
release to get public comment.
-------------------------------------------------------
17:30 Adjourn
raw IRC log: http://www.w3.org/2003/01/21-ws-desc-irc
Received on Friday, 24 January 2003 14:43:18 UTC