Present:
Mike Ballantyne Electronic Data Systems
David Booth W3C
Allen Brookes Rogue Wave Software
Roberto Chinnici Sun Microsystems
Glen Daniels Sonic Software
Paul Downey British Telecommunications
Youenn Fablet Canon
Tom Jordahl Macromedia
Jacek Kopecky Systinet
Sandeep Kumar Cisco Systems
Philippe Le Hégaret W3C
Kevin Canyang Liu SAP
Lily Liu webMethods
Jonathan Marsh Chair (Microsoft)
Jeff Mischkinsky Oracle
Dale Moberg Cyclone Commerce
Jean-Jacques Moreau Canon
David Orchard BEA Systems
Jeffrey Schlimmer Microsoft
Igor Sedukhin Computer Associates
William Vambenepe Hewlett-Packard
Sanjiva Weerawarana IBM
Umit Yalcinalp Oracle
Prasad Yendluri webMethods, Inc.
Regrets:
Dietmar Gaertner Software AG
Amelia Lewis TIBCO
Ingo Melzer DaimlerChrysler
Bijan Parsia University of Maryland MIND Lab
Jerry Thrasher Lexmark
Chair: Jonathan Marsh
Scribe: Roberto Chinnici
Marsh: minutes are approved
Scribe: ACTION: [PENDING] 2003-09-18: Marsh to review the QA operational guidelines.
<Scribe> ACTION: [PENDING] 2003-10-09: Bijan to look into message extensibility Issues (Appendix E, Jacek's review) wrt RDF data, and discuss with Jacek.
<Scribe> ACTION: [PENDING] 2003-11-03: Umit (with help of Glen) will write up a proposal for normative dispatching feature.
<Scribe> ACTION: [PENDING] 2003-11-04: Glen to write up rationale for removing headers (and?) proposal for a generic header-adding property/feature.
<Scribe> ACTION: [DONE] 2003-11-20: GlenD to write up Schemas in imported WSDL stuff in specese.
Marsh: please register for the f2f by the end of the week
... Hotel discount for the March f2f ends on Jan 20th
... Fly to the Nice-Cote d'Azur airport
Marsh: there is a mailing list now for the joint task force on media types
Marsh: need to assign issue numbers to "abstract faults" and
"using rdf in wsdl"
... do we need "Schema extracts for vector, matrix, array"?
PaulD: need them for interoperability; arrays were supported by the section 5 encoding in wsdl 1.1 and interoperated quite well
JacekK: examples or non-normative guidelines ok, but it's a
slippery slope
... other groups should do it but it looks like they don't intend to
PaulD: attempt to define a set of schema features that all processors must support
GlenD: it didn't work in soapbuilders, the xml schema wg should do it
sanjiva: one-dimensional arrays in the primer, but don't go much beyond that
DaveO: proposed standardization of data types in xml schema, but there wasn't support for it
Marsh: options are: a) examples in the primer; b) soapbuilders-like approach; c) define a style to help code generators
<sanjiva> +1 for braindead ;-)
Umit: 4th option: publish a note if there is interest
Marsh: somebody else could publish it
JeffM: putting it in the primer is similar to publishing a note
DaveO: putting it in the primer won't help interoperability
sanjiva: complex data types out of scope for wsdl
PaulD: looking for common pattern for people to use, so the
primer would be sufficient
<TomJordahl> +1
<sanjiva> Correction to minutes (I probably didn't say it clearly): describing XML schema mappings for a complex data type library is out of scope for WSDL IMO
TomJordahl: it's sufficiently important for interop that we can't just say it's out of scope
dbooth: if someone could write it up, I'll include it in the primer
sanjiva: how many data structures are we talking about?
PaulD: n-dimensional arrays
<Scribe> ACTION: pauld to write up examples of schemas for the primer
Marsh: would it be harmful in any way?
Scribe: no replies
GlenD: will send to paul an example of schema for associative arrays
<Marsh> ACTION: Editors assign an issue number for this...
Marsh: new issues for properties and non-xsd languages
... tackle this issue after the f2f
... need to confirm interest for f&p (or lack thereof) at the f2f
GlenD: need more examples for f&p (headers, policy-like, etc.)
JeffM: if we can fix up the issues around f&p, they could be
useful
Kevin: if all functionality provided by f&p can also be done with ws-policy, we'd be in favor of dropping f&p
Marsh: issue raised by roberto is real, let's give it a number and handle it after the f2f
Marsh: do we want to reopen this issue? or do we need to write up a reply to the architecture group?
dbooth: don't need to revisit our decision
... question raised by ws-arch lies beyond wsdl
Marsh: analogy with xml schema
dbooth: we cannot restrict what people do outside of the bounds
of the wsdl language
... we can put a comment in the primer
JacekK: against saying that having multiple wsdl documents describing the same namespace is a recommended practice
dbooth: agrees, we should state that it's a reasonable thing to do but not endorse it
Umit: but people read the primer first
dbooth: we should be neutral to the issue in the primer, just acknowledge this practice
<JacekK> is there any TAG text on the practice of multiple different definitions of one QName (in one symbol space)?
Marsh: add a placeholder in the primer and leave it to the
editors
... it looks like nobody wants to reopen the issue of single-interface
per service
dbooth: are we in agreement that the wg should be neutral about this?
<jeffsch> +1 to ws desc wg neutral re: whether wsdl defines / describes a tns
JacekK: we shouldn't be neutral, it's a bad practice
<jeffsch> see value in allowing a doc to describe a tns
dbooth: uncomfortable to say that it's a bad practice, because it's outside the scope of the language
Marsh: what's the primer schedule? we could discuss it next week
... it would be nice to have the primer ready for last call
dbooth: it won't happen; too many big changes to the language
<JacekK> issue 24 is closed in the issue list...?
GlenD: 3GL developers deal with a relatively simple set of data types
<Marsh> Tom wanted to reopen it, and had some support...
GlenD: mapping all of xml schema to those languages is hard
... soap encoding restricts data to things that can easily be mapped to
object graphs
... real issues with document/literal and limitations in toolkits
jeffsch: isn't the style attribute meant for this?
GlenD: yes, and you could define a style "generated from 3gl"
sanjiva: why is soap encoding a subset of schema? graphs are more general than trees
GlenD: no attributes in soap encoding; you are not really using schema, elements describe nodes and edges
sanjiva: you can build a graph interpretation on top of trees
JacekK: interop is important; 3gl languages are common and they
have different capabilities
... would like a simpler subset of schema closer to 3gl's, but this wg
is not the place to do this
PaulD: restrictions in schema made encoded mode more
interoperable
... graph capabilities are less interesting
<JacekK> what Glen wants is XML-Schema-level interop between 3gl languages; why in WSDL?
Philippe: xml schema wg is being rechartered
Marsh: either we define a subset of schema or ask the schema wg
to do this
... can we use style to do this?
GlenD: do we allow multiple styles?
sanjiva: original proposal had it, but we dropped it
... style on the entire operation and style on the schema are different
<GlenD> Jacek: because web services and WSDL are extremely common use-cases of using XML to talk between 3GL classes/objects
Roberto: style is ok to say "treat this as a graph", but it doesn't seem useful to specify that you're using a subset of schema
JacekK: disagrees, usage is appropriate; should reconsider jeffsch's suggestion of removing style and using attributes in its place
TomJordahl: doesn't like the idea
<sanjiva> -1 to removing operation/@style as it exists now .. :-)
JacekK: will send a proposal to the list
Umit: then @style is not defined in WSDL anymore
<JacekK> ACTION: JacekK to formulate concrete proposal to remove style attribute and handle this using normal extensibility
Marsh: back to the question: is a new style URI appropriate?
GlenD: can always use an extensibility element
Marsh: do we want to craft a proposal to address this issue?
... should we even reopen the issue?
TomJordalh: interest came from discussion on soapbuilders
... but I don't want to bring soap encoding back as first-class
GlenD: 3gl-to-3gl is the problem; restricting the schema data model is the most important thing
sanjiva: in rpc/encoded, people wrote schema with encoding in mind
GlenD: issue is: what will toolkits do when they run into schema constructs that are hard to map to 3gl's?
sanjiva: then you're arguing for a schema subset
Roberto: type system extensibility is enough for now
JacekK: then it would be incompatible with schema-based tools and existing schema documents
PaulD: in wsdl 1.1, different encoding styles applied to the same data
GlenD: but you couldn't validate against the schema
... you could only validate the object model (above the schema)
PaulD: encodingStyle in 1.1 was about how to map the infoset on the wire, and it looks like we lost that
jeffsch: rpc style says "the element has a particular,
restricted form"
... why isn't this the same thing?
GlenD: it is
jeffsch: to clarify paul's point, what we say now is that what
appears on the wire is always the infoset
... now we have a clean description of the messages
... "style" mechanism useful to flag messages as using a certain subset
of schema
Marsh: keep issue #24 closed
... open an issue on improvements to rpc-style or creating a new style
... we narrowed issue 24 to a subset of schema and its relationship to
the rpc-style (or another one)
Umit: being able to apply multiple styles is the issue now
JacekK: any volunteers?
<JacekK> is there somebody brave enough to dare to attempt to subset XML Schema for this issue?
jeffsch: the work can be done separately (after last call, as a note, whatever)
Marsh: add an issue for this anyway, maybe a volunteer will step up
<JacekK> jeffsch is dodging the volunteer problem 8-) Good work, all we'd need is to provide support for it to be doable later.
<jeffsch> can the chair give a good title for this new issue?
Roberto: YASS - yet another schema subset?
<JacekK> 3gl-to-3gl XML-Schema-level interop
Marsh: we decided not to do anything about the graph part
MEETING ADJOURNED