- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Wed, 5 Mar 2003 12:32:30 -0800
- To: <www-ws-desc@w3.org>
- Message-ID: <330564469BFEC046B84E591EB3D4D59C099D3FDC@red-msg-08.redmond.corp.microsoft.com>
Monday
Properties and Features
Majority interest in continuing to work on this.
AM proposal:
Interface Component, Interface Operation Component:
Add {feature} and {properties} properties, which are
sets of Feature Components and Property Components,
respectively.
Binding Component, Binding Operation Component, Port
Component:
Add {properties} property which is a set of Property
Components.
Feature Component:
{name} and {required} properties, which are anyURI
and boolean types, respectively.
Property Component:
{name} and {value constraint} properties, which are anyURI
type and type definition, respectively.
Syntax Model:
<wsdl:feature uri="xs:anyURI" required="xs:Boolean"?/>
<wsdl:property uri="xs:anyURI">
one of <wsdl:value>content?</wsdl:value>
or <wsdl:constraint type="xs:QName"/>
</wsdl:property>
<wsdl:value> is a shorcut syntax representating a constraint to
a single value.
Allow <wsdl:feature>* to <interface> and interface <operation>.
Allow <wsdl:property>* to <interface>, interface <operation>,
<binding>, binding <operation>, <port>.
Processing Model:
Required attribute works like wsdl:required.
Property constraints are rolled up.
Proposal to remove binding (collapse binding and interface) rejected.
7 MEP review (continued to Tuesday)
QA with Karl Dubost.
ACTION: Editors will review specification guidelines by 18 March.
ACTION: Chair and team will review operational guidelines by 18
March.
ACTION: Editors to discuss markup for testable assertions
in the spec and come back with a strategy.
ACTION: Jonathan to recruit a QA contact for the WG.
ACTION: Jonathan to recruit a test contact for the WG.
Tuesday
MEP review
ACTION: Editors of the MEPs to record in that document our
intention that a CR requirement be that MEPs that
prove their utility will be left in. The "utility"
metric is that a binding (not necessarily from this
group) which makes use of that MEP be intereroperable
between two vendors.
ACTION: Editors MEP to suggest meaningful names for our MEPs
ACTION: Editors to rename MEP spec to Part 2, old Part 2
becomes Part 3.
Clarify type and element
issue still open, dependent upon proposal to remove message.
Renaming
portType -> interface
ACTION: Editors to open an issue on One interface per service
port -> endpoint
binding/@type -> binding/@interface
operation/@mep -> operation/@pattern
Fault naming
Proposal is obsolete because of MEP-related changes.
Eliminating message
Topic deferred.
Received on Wednesday, 5 March 2003 15:32:37 UTC