Raw minutes telcon 21/11/2002

Action Items
============

RETIRED
DONE
OBSOLETE
DONE
PENDING
PENDING
PENDING
DONE, pending Schema validation by Gudge

[Long discussion]

Marsh: Would prefer comments in Schema rather than prose in spec 
describing the Schemas.
Gudge: No worries.

PENDING
PENDING

Admin
=====

New drafts for review by next Friday

New issues
==========

* Prasad: express optionality from SOAP headers (from WS-I)
* Youenn: open content model and extensibility

MediaType registration
======================

Marsh: minutes from f2f incorrect. Recall:
* Yes, register mediatype; follow TAG process
* Add issue to spec appendix: text/xml or application/wsdl+xml

jjm: this is what I recall as well. Part 1 contains new
mediatype appendix, with ednote as you have just highlighted.

7) WSDL URI
===========

Marsh: notify TAG we're doing something broken? new TAG issue? 
simply tell TAG we're done?
JeffS: Arthur not on the call.
Marsh: think this is exactly issue 28 (fragment identifier)
Marsh: suggest send message to TAG when we incorporate Arthur's 
text into spec. Reasonnable?

No objections.

8) Alternative schema languages
===============================

Marsh: just read text from Amy. Jack?
Jack: Amy's examples are misleading (or broken)
Amy: why should type and element be reserved for XML Schema?
Gudge: difficult, because in RelaxNG, don't have QNames
Amy: this is why I did it this way
Jack: would be simpler and easier if make them XML Schema specific
Amy: example of such schema that does not support?
Sanjiva: people have been asking for MIME explaination
Glen: link with SOAP w/ attachment?
Sanjiva: two independent things.
Amy: can't use WSDL with other schema language
Sanjiva: yes you can, with new attribute
Jack: what if import RelaxNG and XMLSchema, how would we know 
which schema we point to?
Amy: described in proposed text
Gudge: proposal needs to be refined
Jack: ok, likes the proposal overall
Marsh: include in Dec 6 draft?
Snajiva: must support multiple schema languages. In addition, use 
type element for that.
Amy: impacted by removal of message element
JeffS: add to the spec, be assertive we will support other schema 
languages

Straw poll:
Option 1: reuse element and type attribute
Option 2: used qualified attributes for other schema languages
Option 3: reused element and type attribute for schema languages 
described in XML only

Option 1: 0
Option 2: 5
Option 3: 10
Abstentions: 5

Marsh: option 3
Jack: how to solve Amy's issue?
Gudge: new issue; solve later.
Amy: not permitted; open question.
Marsh: incoporate text for Dec 6 draft, with Jack's issue?
Gudge: yes, will make necessary changes to Amy's text

9) SOAP headers independent of SOAP modules
===========================================

Marsh: just noticed JJM posted mail on XMLP; any action?
JJM: little reaction from XMLP
Glen: do you think we need this? I don't
JJM: fine with status quo

No objection to status quo.

Marsh: won't track this thread any more

10) @@@
=======

Marsh: waiting for revised proposal from Roberto
Roberto: keep it on email for a while

11) Output operation
====================

Marsh: data trader operation. How to move that forward?
Amy: TIBCO feels tied up with feature support and Don's named MEPs.

12) Revised proposal from Amy
=============================

Marsh: (for Barbara and Prasad) broke feature proposal into 
manageable chunks. Had trouble at highler level of abstraction. Amy?
Amy: write of where I think we should be going. Contains a number 
of clarifications. Low enough in impact and flexible enough. New 
element as child of binding (protocolBinding). May contain 
propertyConstraint or featureBindings, which themselves may 
contain propertyConstraints. Impact low, but enough functionalities.
Glen: mechanims like this required. Like some aspects. Overlap 
some other work: protocol binding that wraps up in URI both 
binding to SOAP and to particular SOAP protocol binding. 
PropertyConstraints at SOAP wide level. We're missing ability to 
separate SOAP binding from underneath protocol binding.
JJM: also would like clearer separation between message 
serialization (for example XML SOAP) and underlying protocol 
binding (for example SOAP over HTTP or SOAP over Email).
Glen: support particular property constraints within particular 
operations.
Marsh: continue to email; amend Amy's proposal
JJM: may provide a list of issue brought out so far, so can 
compare the proposals and see missing features. No time for next 
week; maybe week after that.

13) MEP support in operation
============================

Marsh: Don's proposal
JJM: no time to read it
Glen: like it!
Don: link between operations and MEPs
Jack: WSDL MEPs are different from SOAP MEPs
Sanjiva: agree, but don't think this is what Don's proposing
Glen: MEPs should move from XMLP to WS-Arch
JeffS: operations today are a sequence of messages?
Sanjiva: yes
JeffS: so, if had more than one, whether MEP, would be a sequence?
Sanjiva: one possible semantic; would not recommend that
Glenn: branching?
JeffS: if operations are not primitive, why have multiple 
operations per porttype?
Sanjiva: MEP would describe message involved with that specific 
interactions. Input output not enough
Jack: two MEPs in WSDL currently. If go further, will do 
choreography work
JJM: wouldn't choreography build on that fundation?
Amy: yes, current two MEPs are not sufficient
Glen: need define boundary with choreography; but can still 
explore the issue
Amy: not promote definition of MEPs that turn into choreography, 
but should be able to express, for example, request-response MEPs 
with different semantics.
Marsh: what next? how roles work?
Jack: how SOAP MEPs are WSDL MEPs.
Sanjiva: why SOAP dependency? Don is simply suggesting message 
flow semantics.
Jack: pb with example; Don uses SOAP MEP URI.
Marsh: what's benefit if can't reuse SOAP URIs?
Sanjiva: e.g., TIBCO and Microsoft have different semantics for 
output.
Glen: need to connect with SOAP MEPs. Could refer to abstract 
MEPs. Common framework for all spec.
Sanjiva: SOAP MEPs would come at the binding level.
Marsh: rewrite SOAP req-resp MEP in a WSDL friendly way. Better 
if also SOAP friendly. Can't rely on XMLP or WS-Arch. Should come 
up with example. Any one with time and interest?
Sanjiva: current proposal simply extends current model.
Amy: Marsh would like abstract req-resp pattern. Would offer to 
do this, but not sure right person.
Marsh: can't unify SOAP and WSDL MEPs. Need evidence.
Don: will detail changes/addition necessary to unify SOAP and 
WSDL MEPs.

Adjourn.

Received on Thursday, 21 November 2002 12:35:49 UTC