Notes from the OASIS WSRF TC Face-to-Face
meeting
16th - 18th May 2005
Roll Call
The roll call is kept on the TC web site under the meeting
record.
See http://www.oasis-open.org/apps/org/workgroup/wsrf/event.php?event_id=7762
Confirm minute taker
Tim Banks is taking the minutes.
Approve minutes of April 18th telecon
See: http://www.oasis-open.org/committees/download.php/12327
There were no comments and no objections to
approving the minutes.
Action Review
(Bryan) Move issue WSRF109 to open Done.
(Spec authors) – review AppNotes
additions document at http://www.oasis-open.org/apps/org/workgroup/wsrf/download.php/12346/DraftAppNotesIssues63_95_22_52_89.doc
Done. (No comments)
(IanR/TomM) Organise a call on RMD
advertise via the TC web site. Done.
(Bryan) move issues WSRF103, WSRF106, WSRF104 to resolved. Done.
(Bryan) move issues WSRF105 to open. Done.
Agenda Review
Call for AOB
(DaveS) We need an update on WS-Addressing.
Validate closure of isues from updated documents
(IanR) We’ll go through the specs and
review the appropriate issues as per the editors instructions.
WS-Resource:
Issues:
91, 92, 99, 101
WS-ResourceProperties
Issues:
91, 92, 97, 98, 99, 101, 102, 103 (*)
WS-ResourceLifetime:
Issues:
91, 92, 99, 101, 103 (*)
WS-BaseFaults:
Issues:
91, 92, 99, 100, 101, 106
WS-ServiceGroup:
Issues:
44, 58, 59, 69, 87, 91, 92, 99, 101, 104, 103 (*)
AppNotes: Issues: 20, 22, 48, 52,
63, 65, 89, 103
(also need to check whether 91, 92, 99 have any
impact on AppNotes)
The following are the issues:
WSRF89:
Document-literal serialization
WSRF91: Resource Access Pattern reaction to the removal of ReferenceProperties
WSRF92: Update examples to be compliant with the recent version of
WS-Addressing
WSRF99: Examples in the specs use the SOAP 1.2 namespace
WSRF101: Use of non-normative references
WSRF97 QueryResourceProperties WSDL portType does not reference the property it
requires as specified in XML schema
WSRF98: Cardinality of SetResourceProperty content
WSRF102: InvalidDeleteResourcePropertiesRequestContent needed
WSRF63: Which lifetime attributes (ala OGSI) should be specified for resource
properties
WSRF100: Confusion about requirement of using WS-BaseFaults for all faults from
WS-Resources
WSRF106: Not clear how to map faults for SOAP 1.1 and SOAP
WSRF22: QNames as attribute values or text nodes is problematic with
signatures/encryption and intermediaries
WSRF103: Multiple Service Port elements legitimate?
WSRF44: No obvious mechanism to include only members which extend a certain
interface
WSRF58: ServiceGroup WSDL does not need imports for WSRF-RL WSDL/schema
WSRF59: Inconsistencies in ServiceGroups
WSRF65: Need a mechanism to aggregate an operation across several resources in
a ServiceGroup
WSRF69: Content should be declared with minOccurs="0"
WSRF87: InitialTerminationTime in Add method needs to have stronger guarantee
WSRF104: Content Rule Applies in Two Ways
WS-Resource
(IanR) DaveS is chair for this part.
(TomM) Line 211 - we need the isReferenceParametne=true
attribute in the soap:header
(IanR) Yes – that should apply to all
specs.
(Umit) Line 202 – the address for wsa
namespace is wrong.
(TomM) About the removal of non-normative
references: SOAP is non-normative
(IanR) But the only references we make are
in the examples. Anyway, I’ll put it back.
WS-ResourceProperties
(IanR) From the consistency perspective –
we need the ‘Location’ to be the CD-01 name. The same goes for the page footer.
(SteveG) We need to reconsider an issue or
raise a new one: consider relaxing the restriction on RP schema to have element
children only.
Action: SteveG
to review minutes from last face to face re: element children only in RP doc.
(SteveG) Resolution of issue 103 needed
change to wsa:action. How do we get the schema imported into the WSDL?
(IanR) W’ll deal with that when we get to
the WSDL.
(SteveG) What about the ResourceDisambiguator
in responses. We should have ReplyTo and anonymous To in the Reply.
(BryanM) We should take out the header
detail altogether.
(TimB) Yes – that’s just noise.
(IanR) This is a clarification to the SOAP
1.1 issue resolution. The editors should get rid of the headers in the examples
in the specs.
(Unit) we need the wsa:action part to be
there, but not the rest of the stuff
(SteveG) Line 1073 use of consistent InvalidModification
fault.
(SteveG) There is a non-normative reference
to the state paper. Do we want to continue with that reference? I propose not.
No objections.
(SteveG) Line 1850 – removal of references
– we shouldn’t remove OGSI, yes.
(TomR) Right, that wasn’t an issue.
(SteveG) But all of the www.ibm... And ws-caf and ws-rm should go.
(IanR) We should take out refs to
WS-Notification.
(SteveG) Then we need to remove the parts
that describe subscriptions: these are normative references.
(IanR) ok.
(DaveS) Right, so we need to put a warning
notice on the front page as WSDM did.
Action: (DaveS)
Raise an issue to take care of the WS-N Dependency
(SteveG) What about the acknowledgements
section?
(Umit) I’m not there!
(IanR) It’s the chair’s responsibility to
fix it.
Action: (IanR)
Update acknowledgements text and distribute.
(SteveG) Done the reference for the QueryResourcePropoerties
portType…choice
(SteveG) The wsa:action attributes are in
the WSDL, though this
(IanR) Does everyone agree that the right
resolution is to out the attributes in WSDL?
(Umit) So this makes WS-Addressing a
requirement.
(SteveG) That’s right, even if we didn’t
have this in the portType.
(Umit) Well, there is a new namespace for
the wsdl binding, and this is not at last call.
(DaveS) So, we should get rid of this
attribute in the WSDL.
(IanR) The appnotes and Primer should not
refer to the invisible ws-a/wsdl binding, but this might be a timeframe thing.
We need to decide the status of the Primer/Apnotes: are they OASIS-approved
standards, or just other material produced by the TC.
(TomM) That’s an onerous process.
(IanR) It shouldn’t be, if we exploit the
TC.
(MartinC) There is no harm to take it to a
committee draft. I’m not certain that it should go to OASIS standard.
(IanR) we’ll discuss the OASIS process
later in the agenda.
WS-ResourceLifetime
(TimB)
(MartinC) The statements about security
aren’t very useful. Shouldn’t we refer to WS-I?
(DaveS) The reference to WS-Security is
more global than just the BSP security token mechanisms.
(MartinC) But BSP narrows it to something
interoperable.
(TomM) What about the reference to
WS-Addressing – is that right
(IanR) Yes – I should change the one in
WS-RAP
Action: (IanR) Fix WS-RAP requirement for basefaults.
(DaveS) What about the references to WS-N
(DaveS) Need to split the references into
normative and non-normative. (OGSI/SOAP/WS-Security)
WS-BaseFaults
(IanR) What should the wsa:action say for
faults
(DaveS) Need an issue to decide this.
Action: (DaveS) Raise a new issue to
discuss.
(TimB) we need to fix the ‘must be basefault’
statement in WS-RAP.
WS-ServiceGroup
(TomM)…
(IanR) Should the action uri contain the
cd-01 rev number?
(DaveS) If we changed the semantics in the
next version, we would be able to distinguish it via a cd-02.
(IanR) Changing the reference each time we
revise the specs is a pain. We should have something more generic.
(TomM) This is a general problem with
namespaces and versioning,
(MartinC) We should have one WSRF
namespace, or one per specs, which is orthogonal to the versions.
(IanR) At the moment a namespace-per-space
means the schemas are easy to find at the namespace url.
Action: (DaveS)
Propose new issue to discuss namespaces and versioning.
AppNotes
(IanR) Katy isn’t here, but there’s some
news. Katy won’t be able to carry on editing this document. Are there any
volunteers to own it.
(RogerM) I would like to contribute.
(IanrR) We have someone in IBM who could
assist.
(RogerM) Ok – it will be a joint effort.
(IanR) Issue 20 isn’t done, can’t be
closed. 22 and 48 are ok. Resolution to 52 needs to use the new InvalidModification.
63 is Ok. 65 missing. Resolution to issue 89 in section 6.1 (line 826) needs a
reference to WS-I. 103: Not done.
(IanR) Editors should update before 10:10 tomorrow.
(Doc editors to upload new drafts before start of meeting)
New issues to consider - Bryan
WSRF 110: BaseFaults does not allow open content
(SteveG) The original idea was that extension should be used
to include open content.
(BryanM) But this doesn’t help if we want to design a
generic listener which doesn’t understand the extensions because they don’t
have the WSDL.
(TomM) but the extension-via-any can’t be understood either.
(BryanM) The any stuff can be logged even though it can’t be
(TomM) The original reasoning was that the type derivation
introduces rigour into the definition which makes it possible to
(Umit) It’s easier to implement the any kind of
extensibility, but one loses the type information, if that is interesting.
(BryanM) Also, we shouldn’t be defining a Basefault element
if we don’t want peole to use it – only a type.
Action: Move to open
WSRF111: Missing fault messages for unexpected faults
(DaveS) Should internal faults be described by the specs.
(SteveG) We could say the ‘a fault is sent including the followin’
without specifying what the complete set of faults are.
Action: Move to open
Issues raised already in the meeting,
(TimB) Raise an issue to take care of the
WS-N Dependency – whether to split that part from the main specs
(BryanM) This will be issue 112
Action: (Bryan) Move to Open
(DaveS) We also need to deal with
WS-Addressing as a general status page issue.
(Bryan) This would be issue 113
(IanR) This would raise a red flag
(DaveS) That would happen anyway
(IanR) Can we defer this.
(MartinC) It’s not worth it right now
(DaveS) Propose new issue to
discuss namespaces and versioning.
(Bryan) This is issue 113.
Action: Move to open.
(DaveS) What action URI should be used for
faults.
Action (Bryan) move to open
This will be issue 114.
Issue Resolution
(MartinC) Now that there is consensus around WS-Addressing
there is no need for a WS-MD-based mechanism, but this embodiment describes a
different pattern whereby there is reference information that is not available
when the EPR is created. This document http://www.oasis-open.org/apps/org/workgroup/wsrf/download.php/12515/wsrf-WS-Resource-1.2-draft-02-addition1.doc
describes a WS-A based equivalent
(SteveG) Does this satisfy the rules for embodiments?
(Umit) Lines 62-64 is where the details are.
(DaveS) I see the temporal separation issue..
(SteveG) but why does it need a new namespace?
(IanR) Isn’t this a different issue?
(MartinC) I (and Anish) would like to coinsider
(SteveG) So, I see that it satisfies the rules, but what
value is it over the existing WS-A embodiment?
(Anish) We wanted to decouple the resource identifier from
the endpoint. The WS-Addressing WG don’t describe the issue of comparison of
references.
(DaveS) What’s to prevent me from packaging the EPR and the
identifier together once they’ve been found out?
(MartinC) This is W3C-theology-compliant.
(SteveG) I don’t think it is any more compliant.
(Umit) How does the lifecycle work?
(IanR) I think the EPR and identifier are created at the
same time and returned to the client.
(MartinC) Right, but they can used independently – the id
can be used at a different endpoint.
(IanR) It would be possible to have this same scheme by
making the identifier into a reference parameters.
(MartinC) Right, but that would mean figuring out what else
was in the EPR, which is against the spirit of EPRs.
(Anish) In addition to the decoupling part and the
comparison part there is the problem of having multiple reference parameters in
an EPR.
(TomM) The comparison issue s has been considered in WS-A
and WSRF has no normative requirement for this.
(Umit) Why does this identifier have to be separate from the
EPR?
(MartinC) Because the EPR is opaque.
(Anish) Yes, if we defined refparms that can be used
independently of the rest of the refparms that would do the job, but we don’t.
(Umit) But anyone can do what they like with refparms.
(TomM) So you want to standardise the identifier and and get
the issue of identity that was thrown out of W3C WG into the WSRF TC.
(IanR) One could define a new embodiment which captures the
requirements, but doesn’t need the new namespace in Anish’s proposal, instead we
define a new element to go in the EPR.
(anish) So, we define a refparm in a schema and define an
embodiment that says the EPR will contain this refparm?
(IanR) Yes. So the proposal is to morph this issue into a
new proposal to replace the WS-MD embodiment.
(Anish) So, this at least pins down where the identity is
within the EPR.
(DaveS) Seems to me we don’t actually have to change the
current spec.
(MartinC) But we need to ensure that there is a global
wrapper.
Action: (IanR) A subgroup will work on a proposal and
discuss again Tomorrow at 10:30 after an 8:30 am start.
(BryanM) This about which of text,
pseudo-schema appendix and schema is authoritative.
(SteveG) The real issue sis between the text and the schema
in the files. Text contains more menaing, schema is less ambiguous.
(IanR) And schema is what implementations use to construct
implementations.
(MartinC) It doesn’t really matter which we choose. It is
only a matter or managing discrepancies when they occur.
(TomM) We spend more time on the text specs. We don’t spend
much time on the wsdls and xsds.
(IanR) The motion is that the separate xsd and wsdl files
are authoritative over the text.
Carried (6-5).
Where there is
disagreement between the separate xml Schema and wsdl descriptions of the
messages defined by this specification and XML Schema and wsdl the normative
descriptive text (including any pseudo-schema), the xml schema and wsdl takes
precedence over the text.
Action: (Bryan) Move to resolved.
Meeting suspended at 18:00
Resumed 8:30 17th May
ServiceGroup
(Bryan) Ned to consider neew issues described here: http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200505/msg00070.html
(DaveS) What do these things do?
(William) We get rid of the content element, and we need to
express the relationship of the properties in the SG to those in the member
resource. We need to know that the SG has all the properties the member
does.
(TomM) It sounds like a complex assertion to make – if we say
anything about coherencey.
(DaveS) We could say something about the
(IanR) Looks like there are some new issues here.
(William) we need a new issue to describe Advertisement of
the entire RP document in a SG entry. And
(DaveS) Couldn’t this be done by a new content rule that
specifies the RP document be in the conent?
(William) That doesn’t exclude other content in the entry.
(DaveS) Not sure about that.
(TomM) we need a new wrapper (instead of Content) to contain
the RP document.
(William) We need a new membership content rule allow select
resource properties from any member content – for example ResourceId.
Action: (Bryan) Create a new issue for SG containing
RP document.
(DaveS) Also in the email is a question about set/bag
semantics for SG members. Currently its bag, set is too restrictive.
(TomM) This was discussed at the last face to face
(DaveS) And several times in the OGSI days.
(William) But we only have one kind of membership – we don’t
need the freedom.
(TomM) The implementation can do that within the current
spec. The SG can advertise that, but we’ll run right into the identity issue.
(TomM) There are lots of ways to paint a WS-Resource, but
they all end up being the same weight.
(DaveS) If we removed the concept of the Resource from the ServiceGroup
any lifetime semantic would have to be re-invented on whatever replaced it.
(TomM) Proposed to close with no action.
No Objections
Action: (Bryan) Move to Closed – no action.
Issue review
WSRF89: Document-literal serialization Close
WSRF91: Resource Access Pattern reaction to the removal of ReferenceProperties Close
WSRF92: Update examples to be compliant with the recent version of
WS-Addressing Close
WSRF99: Examples in the specs use the SOAP 1.2 namespace Close
WSRF101: Use of non-normative references Close
WSRF97 QueryResourceProperties WSDL portType does not reference the property it
requires as specified in XML schema Close
WSRF98: Cardinality of SetResourceProperty content Close
WSRF102: InvalidDeleteResourcePropertiesRequestContent needed Close
WSRF63: Which lifetime attributes (ala OGSI) should be specified for resource
properties
WSRF100: Confusion about requirement of using WS-BaseFaults for all faults from
WS-Resources Editors should see Text from Tom.
WSRF106: Not clear how to map faults for SOAP 1.1 and SOAP Close
WSRF22: QNames as attribute values or text nodes is problematic with
signatures/encryption and intermediaries Close
WSRF103: Multiple Service Port elements legitimate? Need to confirm wsa:Ation in WSDL – fault
aspect and AppNotes issues
WSRF44: No obvious mechanism to include
only members which extend a certain interface Close
WSRF58: ServiceGroup WSDL does not need imports for WSRF-RL WSDL/schema
WSRF59: Inconsistencies in ServiceGroups Close
WSRF65: Need a mechanism to aggregate an operation across several resources in
a ServiceGroup Close
WSRF69: Content should be declared with minOccurs="0" Close
WSRF87: InitialTerminationTime in Add method needs to have stronger guarantee
WSRF104: Content Rule Applies in Two Ways Close
(IanR) For the wsa:action for Faults, we
need a common url for all faults. If this is defined in the WSDL it’s obvious
it goes in the fault header. Also there is a default action, but we can specify
it elsewhere.
(Umit) But according to the WS-Addressing
spec we need a marker in the WSDL.
(IanR) I Disagree. The default pattern for
faults namespace/portType/Operation/Fault::faultname but it can be overridden
by other specs (as WS-Addressing indeed does).We need an action URI for WSRF,
and a way of declare it: url should be http://docs.oasis-open.org/wsrf/fault,
and we need clarification of the WSA spec .
(SteveG) Can we close issue 103? We need to
decorate the WSDL but issue 103 is not descriptive of this. We need a new
issue.
(IanR) Can we solve this? The problem arises because we
agreed the supremacy of the wsdl over the text, if it were the other way round
we would be able to rely
(DaveS) Is there agreement to change the precedence rule?
(No objections, 4 abstentions)
The new text should be:
Where there is
disagreement between the separate xml Schema and wsdl descriptions of the
messages defined by this specification and XML Schema and wsdl the normative
descriptive text (excluding any pseudo-schema), the normative text xml will
take precedence over the separate files. The separate files take precedence
over any pseudo-schema and any schema and wsdl included in the appendices.
Issue WSRF107
(IanR) The new embodiment proposal is http://www.oasis-open.org/apps/org/workgroup/wsrf/download.php/12698/wsrf-ws_resource-1.2-spec-wd-05.107.doc
(William) I don’t understand the value of
this if there are no comparison semantics associated with it. How does it help
if two examples of wsrf-r:ResourceIdentifier are the same?
(tomR) There’s a mistake on line 286 – the uri
should be an attribute, but I agree we need to do it within the syntax of refparms.
(DaveS) We need to decide what to do: we
should decide about the MD
(William) Seconded
(DaveS) about the removal of the WS-MD
embodiment.
(No opposers, 2 absentions)
(DaveS) Carried. Should we also (in
principal) add an embodiment with the ability for the server to provide a
specific resource identifier.
(William) This has been discussed in W3C.
We shouldn’t be using WSRF to fix this fundamental issue of addressing on the
web.
(MartinC) This is the same as embodiment
1.
(why doi we need it
(Anish) Because it prevents IBM and HP
sharing the knowledge about the identifier if they don’t have common holder for
it.
(William) Yes. So this is a problem in
WS-Addressing.
(Anish) so, we shouldn’t be in business of Reparms,
and everybody should be free to
(William) Yes. Standardizing the systems
become more brittle. Current;y, with only EPRs no-one cares what’s inside them.
(Anish) But all people will see is an
opaque epr unless they understand what’s inside.
(William) This encourages people to look
inside EPRs.
(Anish) But everyone will look inside.
(William) Yes, but for security reasons
only.
(MartinC) Everyone who did CORBA had the
same issue and cheated so that they could tell when an object reference
changed.
(Umit) We have a use case to do with
gateways that would make use of the identifiers.
(TomM) Right, but what are the semantics –
we would have to agree that part, and that’s where CORBA struggled.
(DaveS) Have we had enough discussion now?
The proposal is to add the new embodiment section.
In favour: 3, Against: 6, Abstaining; 5
Action: (Bryan) Move to resolved.
(MartinC) I propose we remove the ‘embodiment’
stuff, since there is only one way to do it – using WS-Addressing.
[Lunchtime]
Process Update
(IanR) There are changes to the standards
approval process see: http://www.oasis-open.org/apps/org/workgroup/wsrf/download.php/12694
(page 6)
Issue review (continued)
(continued from before lunch)
(MartinC) I propose we remove the
‘embodiment’ stuff, since there is only one way to do it – using WS-Addressing.
(Umit) I second Martin’s motion.
(MartinC) We should just say that WS Addressing
is the only form of WS Resource Reference (by modifying section 2.4) and remove
the WSDL embodiment section.
(SteveG) We should also move the text from
section 3 and 3.1 into the AppNotes.
(DaveS) Let’s Vote
In favour 12, Abstaining 1.
Action: Raise
a new issue. (116) and move to resolved.
Issue WSRF110: Basefaults does not allow open content
(DaveS) We need to decide if ew can
provide a schema validation for general errors.
(BryanM) Or declare that the faults may not
be validatable.
(DaveS) Would a MustIgnore=true attribute
be acceptable?
(BryanM) Up ‘till now everything as been validateable.
(Umit) Well, in that case, the ‘any’ element
isn’t a good idea.
(BrynaM) right, but at least the rest of
the fault would be validateable
(BryanM) We could do something with
substitution group
(Umit) But no-one understands them, and no
tools.
(SamM) what about using <FaultCause
type=baseFault> as the extension point.
(bryanM) Seems to me we lose the qname of
the derived fault in the process of nesting the fault – it ends up begin a Faultcause
element.
(TomM) I think we need to declare Basefault
as abstract and use a substitution group – that’s the only way.
(SamM) So we need an xsd:any in the Basefault
top level, and a sequence of faultCauses with an xsd:any.
(IanR) I don’t see why we have maxoccurs=unbounded
for FaultCauses – there should be max of one.
(DaveS) So we need a faultCause with an xsd:any
type and an extra xsd:any to allow element extensions of base Faults.
Action: (Bryan) Move to resolved
Issue WSRF 111: Missing fault message for unexpected
faults.
Action: (Bryan) Move to close as covered by the
resolution to issue 100.
Issue WSRF 112: dependency on Notification
(SteveG) This is to deal with the possible
separation of the specs to refer to the still-evolving WS-N specs.
(TomM) We could wait until after the 60-day
review period to fix it. What about the status declaration on the front of the
specs.
(DaveS) I propose we close without action.
No Objections
Action: Move
to closed
Issue WSRF113: Correlation between NS and location
(IanR) We have had the idea that Namespace
URL points to the document, and we change namespace with every rev of the
document. This gets worse when we start to go through a review process which
demands name changes.
(DaveS) Are there any objections to
decoupling namespaces from document names
(No objections)
(DaveS) What should we call it?
Proposed to call it http://docs.oasis-open.org/wsrf/rp[w]-1
(DaveS)Any objections?
None.
Action: Move
to resolved.
(Umit) what about the using a RDDL document
to pride an indirection to the various documents and switch to new versions
when required.
(MartinC) I don’t think it buys anything if
there is only one document referenced by the namespace.
Suspended 16:30 for spec editing session on resolved
issues.
Resumed 8:50 18th May
Issue Review
WSRF114 wsa:Action URI for fault messages/WSRF110
(IanR) I propose we need to change the
resolution of WSRF114 so that each spec describes the action URL. Proposed
text distributed here: http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200505/msg00089.html
No objections.
Action: (Bryan) Move to resolved.
Acknowledgement text
The new list of people to be acknowledged
includes voting members. Observers may included if they so request.
[Two people added by request]
Action: (IanR)
Mail the list and the process to the mailing list.
Status section
Needs update per Ian’s note: http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200505/msg00089.html
WSRF103 Multiple service Port elements
(IanR) Is this verified?
Yes
Action: (Bryan) Move to closed
WSRF109 Clarify authoritative precedence order
(IanR) Is this verified in all the specs?
Yes
Action: (Bryan) Move to closed
WSRF113 Correlation between NS and location
(IanR) We need to change the pointers in
the appendices to say the wsdl/xsd are located at the namespace URLs. Wsdls/xsds
may need to be renamed as (eg) “rpw-1”
Action: (Bryan) Move to resolved
WSRF115 SG advertising RP doc
(TomM) Our current statement about content
implies possible incoherence between Entry resource content and
SG/Entry/Content. The new proposal of RPDoc requires coherencey.
(IanR) This would be bad – it’s a burden on
the implementers.
(TimB) We need to say that the content
contains a document satisfying the schema of the member service RP Document.
(TomM) We need the statement about schema
and that the contents SHOULD be consistent.
(William) So how can I say that in fact the
results are coherent?
(SteveG) This is only possible with Policy.
Action: (Bryan) Move to resolved.
Date for next Face-to-face
Option 1: Week of 12th
Sept in the UK. This will be at Fujitsu.
Option 2: (depending on WS-N) Week of 19th
Sept in the UK. This will be at Fujitsu.
Detailed schedule depends on WS-N, probably the latter half
of each week.
[Editing session to include and approve latest resolutions]
Ballot for approval of committee drafts
(IanR) This needs 14 approval votes.
(DaveS) The site lists 25 voting members, so we only need
13.
(MartinC) Charis and secretaries are extra.
(DaveS) So that’s 2 chairs and secretary – 28.
(IanR) Let’s do things spec by spec.
(TomM) I propose that WS-Resource 1.2 WD-06 be approved as a
committee draft.
(MartinC) Seconded
In favour: 14 present, 2 via phone/IRC. No Opposers, No
abstentions.
(TomM) I propose that WS-ResourceProperties 1.2 WD-07.1 be
approved as a committee draft
(MartinC) Seconded
In favour: 14 present, 2 via phone/IRC. No Opposers, be
approved as a committee draft
(TomM) I propose that WS-ResourceLietime 1.2 WD-09 be
approved as a committee draft
(MartinC) Seconded
In favour: 14 present, 2 via phone/IRC. No Opposers, No
abstentions
(TomM) I propose that WS-BaseFaults 1.2 WD-06 be approved as
a committee draft. (MartinC) Seconded
In favour: 14 present, 2 via phone/IRC. No Opposers, No
abstentions.
(TomM) I propose that WS-ServiceGroupBaseFaults 1.2 WD-05b be
approved as a committee draft.
(SteveG) Seconded
In favour: 14 present, 2 via phone/IRC. No Opposers, No
abstentions.
(TomM) I propose that WS-AppNotes .2 Wd-01 be approved as a
committee draft.
(SteveG) Seconded
In favour: 14 present, 2 via phone/IRC. No Opposers, No
abstentions.
Review of Primer examples
(TimB) ShoppingCart and Printer examples illustrate the need
for EPRs to addresss components of the system.
(TomM) Should the aggregates be serviceGroups?
(TimB) No, that’s more complexity than is needed.
Action: (Tim) Construct an example based on Service
group to enable the group to judge.
Next Conf call
Next telecom will be June 6 sharing the time with WS-N.
Close
Closed 12:10.
Summary of actions
(SteveG) to review minutes from last face-to-face
re: element children only in RP doc
(Editors) Follow this new instruction about
the soap headers in examples; only include required wsa:action element.
(Bryan) Move issues WSRF110 and WSRF111 to open.
(IanR) Update acknowledgements text and
distribute to editors.
(DaveS) Raise an issue to take care of the
WS-N Dependency. (112) Done
(DaveS) Propose new issue to
discuss namespaces and versioning (113). Done
(DaveS) Need a new issue to decide on
action uris for faults (114). Done
(SteveG) Review minutes from last face to
face re: element children only in RP doc.
(Bryan) Create a new issue for SG containing RP document
(115) Done
(IanR) Fix statement in WS-RAP about requirement
for basefaults.
(Bryan) Move issue WSRF109 to resolved
(Bryan) Issue WSRF105 Move to Closed
– no action.
(Bryan) Create a new issue for SG containing RP document.
(115)
(Bryan) Close issues WSRF89, WSRF91, WSRF92, WSRF99, WSRF101, WSRF97,
WSRF98, WSRF102, WSRF63, WSRF106, WSRF22, WSRF44, WSRF58, WSRF59, WSRF65,
WSRF69, WSRF87, WSRF104.
(Bryan) Move issue WSRF107 to resolved
(Bryan) Move issue WSRF110 to resolved
(Bryan) Move issue WSRF111 to close as covered by the resolution to issue WSRF100.
(Bryan) Move issue WSRF112 to close (no action)
(Bryan) Move issue WSRF113 to resolved.
(Bryan) Raise a new issue. (116) to describe removal of embodiments 3.2
and move to resolved.
(Bryan) Move issues WSRF114 and WSRF110 to resolved.
(Bryan) Move issues WSRF103 and WSRF109 to closed.
(Bryan) Move issues WSRF113 and WSRF115 to resolved.
(Tim) Construct a Printer/ShoppingCart example based on
Service group to enable others to judge.