Notes from the OASIS
WSRF TC Teleconference on
9th August 2004
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=4800
Approval of minutes from Face-to-Face meeting (27/28th
July)
See: http://www.oasis-open.org/committees/download.php/8607/
There were no comments and no objections to approving the
minutes.
Other Action Review
(Bryan) Re-categorize issue 48 as an application note. Done
(AlanW) Create an issue to discuss the creation of a ‘Usage Notes’ (Primer)
document. Done.
(SteveG) Propose text to resolve issue 4. Carried Forward
(MartinC) Raise a new issue to address Schema discovery on a dynamic property,
including the cardinality within the RP document. Done.
(TomM) Write resolution for issue 10. Carried Forward
(MartinC) Raise an issue to elucidate the meaning of ‘default’ to (separate
this from issue 10). Done.
(Bryan) Move issues 56 through
to 60 to ‘open’ state. Done
(Bryan) Move new issues from
the meeting to ‘open’ state. Done
(Bryan) Raise new issue to
describe requirement for aggregation operations. Done
(Bryan) In issue 1, record WSDM’s
interest and add the requirement to normatively describe the portType
aggregations process. Done
(Igor, Anish and SteveG.) Create new document to abstractly describe the
implied resource pattern and what it means to satisfy it (etc). In Progress
(Sam) Raise a new issue to consider an identity mechanism. Carried Forward
(Chairs) Upload new issue priorities list to web site. Done
Acceptance of
New Issues to the issue list.
Issue 62: Basic Profile conformance
(?) Aren’t the specs already conformant?
(Anish) Maybe, but we should keep an eye on them as things
evolve.
(Dave) Any objections to accepting the issue?
(None)
Action: (Bryan) Move to open
Issue 63: Lifetime attributes (ala OGSI) for resource properties.
Action: (Bryan) Move to open
Issue 64: Rules for schema defaults
Action: (Bryan) Move to open
Discussion Topics identified
at the end of our F2F
Requirements document
(DavidL) There should be something next week. Review at the
next call.
Action:
(Ian) Add Agenda item to review requirements doc at the next call.
App
notes document
(AlanW) Solicitation for collaborators made via mailing
list. Draft outline proposed.
Action:
(Ian) Add Agenda item to review outline of app notes doc at the next
call.
Schedule for the interop
(Ian) We need an agreed scenario document, and we need a committee draft to
drive the interop implementations.
(DaveS) At the next face-to-face we need to discuss the
scenario doc and the schedule.
Issues review
WSRF48: Specify behavior of nillable properties
(AlanW) This should show up in the App Notes document.
(Bryan) Currently the issue is open against that doc.
(DaveS) Keep it that way for now.
WSRF1: Interface
association is lost with the required aggregation model
(SteveG) The problem is that when portType creation has been done, we end up
with a most derived portType, but no way to detect its origin from other
component portTypes. In WSDM it has been suggested to (1) decorate the portType
with an attribute to list the origins. This is similar to how it will end up in
WSDL 2.0, and prepares the way. Another option is to (2) decorate operations or
(3) to list associations in a resource property. (+… see issue text)
(DaveS) This would help tooling which exploits WSDL 1.1: the
basic use case is discovery.
(??) (Discussion about uniqueness of operation names)
(WilliamV) We need the operation names to be unique, so the
operation name will correlate with one of the originating interfaces.
(DaveS) There seems no additional information contained in
options (2) or (3) over option (1).
(SteveG) Tooling can display the operations in WSDL 1.1. The
migration into WSDL 2.0 is simply to remove the operations in favour of the
extension mechanism.
(DaveS) The consensus seems to be to go with option 1
(Attribute on portType). The semantics of the attribute need to be spelled out.
(No Objections)
Action: (SteveG) Make proposal for text.
(SteveG) Should this go in the RP document?
(WilliamV) It should go as an appendix and then can move
elsewhere if needed.
Action: (Bryan) Move issue to resolved.
WSRF20: Notification message format not clear
(DaveS) This seems to be about notification
– can’t we punt it to WS-N?
(GlenD) WS-N leaves it open. The receiver
of a property change event might not be able to tell where what property has
changed. The text doesn’t explain the need to search the body of the message to
find the element. It’s an interoperability issue.
(DaveS) Is this is issue going to be
considered by WS-N?
(WilliamV) Notification is not going to
solve this.
(WilliamV) We could add that it’s the
first occurrence of the element which describes the change, open content
textually following can contain following/related notifications.
(DaveS) We need to say that if an event is
wrapped, the semantics of the wrapping will need to determine how to retrieve
the values.
Action: (Glen)
Propose wording to mailing list.
(DaveS) Issue is unresolved until the text
is considered.
WSRF24: XPath evaluations in namespaces defined or not
(WilliamV) Namespace abbreviations may
exist outside of xml scope, so what do they mean?
(SteveG) But in WSRF uses, xml always
exists.
(WilliamV) Should I look only on the
current xml element, or all the elements in scope? If things are added,
prefixes may appear which weren’t anticipated. So, we should only observe
prefixes that are in the current element.
(SteveG) Is this a best practice
requirement?
(Jeff) There is a tie-up with WS-security
here. We need to avoid ambiguities between creation and processing of digital
signatures cause by namespace changes as elements are wrapped.
(DaveS) The re-specification of the
namespace in each element seems safest. For xPath this is the xPath itself or
the query expression wrapper.
(Jeff) We can’t say that it must be
declared lower down – since there are syntax rules to deduce namespaces from
higher scopes. Some tools exploit this and remove lower level namespace
declarations.
Action: (WilliamV) Start a mailing list discussion.
Action: (Ian) Continue discussion next telecom.
Meeting
closed: 1:30pm.
Summary of actions
(SteveG) Propose text to resolve issue 4. (Carried
fwd from f2f)
(TomM) Write resolution for issue 10. (Carried
fwd from f2f)
(Sam) Raise a new issue to consider an
identity mechanism. (Carried fwd from f2f)
(Bryan) Move issues 62 through to 64 to Open.
(Chairs) Add agenda item for next face-to-face:
discuss the scenario doc and the schedule.
(Ian) Add Agenda item for the next
call to approve outline for the Requirements doc
(Ian) Add Agenda item for the next
call to approve outline for the App Notes doc
(SteveG) Make a proposal for text to resolve issue 1
(Origins of interface aggregation) to mailing list.
(Bryan) Move issue 1 to resolved.
(Glen) Propose wording to resolve issue 20
(Notification message format) to mailing list.
(WilliamV) Start a mailing list
discussion for issue 24 (xpath Namepsace).
(Ian) Continue discussion next
telecom.