Notes from the OASIS
WSRF TC Face-To-Face meeting
July 28th and 29th 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=5432
Approval of minutes from previous meeting (12th July)
See: http://www.oasis-open.org/apps/org/workgroup/wsrf/download.php/7732/
There were no comments and no objections to approving the minutes.
Other Action Review
There were no comments on the minutes and no objections to approving them.
(Bryan) Move issue 16 to ‘resolved’, issues 23 & 34 to ‘closed’ & issue 48 to ‘open’ Done
(Bryan) Open new issue as a result of the requirement from WSDM: Ability to register for notification when any of the properties changes. Done (issue 55)
(SteveG) Draft detailed proposal for new ops to resolve Issue 21: Factoring of SetResourceProperties. Publish to mailing list. Done
(SamM) Propose resolution text for issue 48 (Nillable properties). Publish to mailing list. Outstanding (but See below)
(IanR) Cancel phone call on July 26th Done
(SamM) Publish a list of the errata on the published drafts to the mailing list. Done
Agenda bash and Call for AOB
(MatinC): Is the document management sorted out.
(DaveS). Document review is described in the issues document
(MartinC) Please can we discuss because tracking continuous small changes is hard. We need a plan for a document release cycle.
(DaveS) Agreed.
Issue review
Issue 48: Nillable properties
(SamM): The document is fine– just needs some explanatory information.
(TimB): We can produce a document containing this kind of non-normative information. Please publish material to the mailing list.
(AlanW): What’s the difference between the whitepaper and non-normative info.
(IanR) Whitepapaer explains concepts and puts stakes in the ground, useful for explaining what the WSRF TC is about. It is not a deliverable of the TC.
A primer could be deliverable of the TC.
(AlanW) In other OASIS TCs, this has been called an implementers guide. How are return codes interpreted etc.
(DaveS) We are gathering information for such a document.
Action: (Bryan) Re-categorise the issue as an application note and (AlanW) create an issue to discuss the creation of a ‘Usage Notes’ document.
Issue 4: GetResourceProperty on property document with xsd:any
(SteveG) Properties can be made dynamically visible – for example a stack trace is useful, but not obviously part of the resource property. The question is how to respond to a request for a property which does not exist. One proposal is to return a fault, or return an empty element (since the property is potentially there).
(William) It is useful to diagnose typos in requests.
(Anish) Getting an any is the same as a property that is optional, but not present.
(TomM) It should be up to the implementer to decide the meaning of any.
(SteveG) Need to distinguish the use cases between dynamic properties and extensibility. An extensibility use should reject unknown requests.
(DaveS) Extensibility is guaranteed by the ‘cut and paste’ rule for composition.
(SteveS) a) for minoccurs=0 a nil response is right (Agreed)
b) For an instance document with a dynamic ‘stacktrace’ a request for ‘stooktrace’ should return an error.
c) What if there is a request for a property that sometimes is present?
(TomM) The server may behave as if it’s there, or if its not. It may even depend on the timing of the request vs the creation of the property by the service we can only describe what the service could do.
Action: Steve to propose text. (Hopefully, for review later in the meeting)
Issue 9: Need an API to list all properties
(DaveS) Reads proposed recommendations from Steve here:
http://www.oasis-open.org/archives/wsrf/200406/msg00070.html
(TimB) What is the use case – what are the ‘metrics’ that can exploit these dynamic properties?
(WilliamV) An example is a printer in front of which is placed a proxy which counts pages. A printer might have paper size, speed and ‘any’ published on a dmtf site. The any can be used to hold a newly-invented page count.
(SteveG) This seems the same as issue 4 – asking the service if a qname is valid as a property name.
(Anish) Perhaps we need a different extensibility mechanism (rather than xsd:any).
(SteveG) We chose xsd:any because the document can still be validated when xsd:any is included as a child element - xsd: any fits the bill.
(Anish) But we’re not valdating the document that comes back to the client.
(DaveS) but the client can validate the property values.
(SteveG) If the printer designers want to introduce a new property they can cut and paste (WSDL1.1) document and extend it, or they can introduce it via the any, and always call it dynamic.
(MartinC)We should have more restrictive ‘any’s in application-specific domains (such as WSDM or a manufacturer-extension).
(DavaS) Yes, but we are defining a general mechanism.
We need to decide:
- Do we need a scheme for obtaining the info?
- Is it Via resource property or via operation?
- Do we need qnames known by the service, present at the service, and do we need to set the schema?
(TomM) It’s not clear what the schema would add over the qname + schemalocation – the clients mostly can’t use the schema dynamically to discover the meaning of the property.
(IanR) We need to distinguish the need to know which properties are defined, and issue 27 which is about the properties currently ‘present’ (non-empty).
(William) There are three issues. Get ‘known’ properties, get ‘present’ properties, and get all the values.
(TomM) we need to rationalize the term ‘present’ vs ‘known’ which is interesting in the case of minoccurs=0. This would produce an empty response.
(SteveG) Is there a distinction between ‘present’ and ‘known’ if we include ‘empty’ as a valid response?
(Anish) ‘Known’ would return all qnames – even those created dynamically.
(IanR) Seem agreed that issue 9 is a requirement. We need to discuss the details.
(long…) discussion produced this picture:
Where
§ R1 is <GetRPResponse/> (A response to a request for a property which has minoccurs=0 and for which there are no property values.)
§
R2 is a reponse to a request for a non-nill value
element.
<getRPResponse>
<tns:something/>
</getRPResponse>
§
R3 is a in response to a request for a value which
is nill:
<getRPResponse>
<tns:something xsi:nil=true/>
</getRPResponse>
§ R4 is a ‘Qnames not recognised’ fault.
(SteveG)
Proposed that we need two resource properties:
- WSRP: AllowedRPQnames
- WSRP: PresentRPQNames
Neither is required, and either can be present without the other.
Both properties would be lists of structures of two values, a url indicating a qname and a url indicating schemalocation.
We also need to address the need for minoccurs/maxoccurs of the property.
Action (Martin Chapman) Raise a new issue to address Schema discovery on a dynamic property, including the cardinality within the RP document – need more information in the Allowed/Present RPQNames variables.
(Igor) Do we need this minoccurs/maxoccurs/nillable info? – it could be simply read from an offline specification (description) of the service written in English.
(Anish) Then why do we bother in the case of the statically declared RPs?
(SteveG) A solution to the new issue is to define an operation GetRPDecl(QName) which returns an xsd:element with the additional information on it.
(DaveS) We are going to add this stuff:
Proposed a) A new resource property – allowedRPQNames, ie those which will not throw ‘unknown resource’ fault.
This properties will return the relevant RP QNames and the schemalocation.
(No objections)
Proposed b) A new resource property – presentRPQNnames, which indicates a property of the relevant name in the instance document.
This property will return the relevant RP QNames and the schemalocation.
(No Objections)
Proposed c) A capability - GetRPDecl (QName) - to return the current RP document declaration ( minoccurs/maxoccurs/nillable etc) for each QName requested.
(No Objections)
Issue 10: Mechanism to express metadata on properties such as ‘Read Only’
(IanR)Where can we put this information?
(SteveG) In OGSi, putting it into the schema broke xml tooling because it exploited open content – it needs to go into a different document. We need to agree what the properties are and where to put them are, for example: 1) ‘Appinfo’ in the xsd schema (which is a child of annotation) 2) Use the ‘any’ attribute, but tools really don’t like the latter. 3) A separate metadata document.
(William) Are these things needed at design time, run time or both?
(SteveG) Both.
(Igor) So we could use the annotation at design time and pull out the attributes into a separate document at runtime, if needed?
(SteveG) Yes, that could be done.
(DaveS) Can the metadata be moved out into the new GetRPDecl(QName) operation.
(SteveG) Yes. But that leaves the design time question. Having one document (all in the Schema) is neat, but so is the ability to deploy a service independently from the design stage which suggests a separate deployment document.
(DaveS) There may be some properties which are invariant wrt implementation – eg current time is read only – it can’t be made settable.
(SteveG) Yes, but there’s a lot that is independent.
(Lily) Will the attributes be extensible?
(SteveG) Yes, they need to be.
(DaveS) Proposed: To add metadata to the RP declaration.
(No objections)
Action: (TomMaguire) Write a description of a new metadata document to hold the info, and an operation for runtime access.
(DaveS) So the properties in OGSi were: Modifyable (Boolean), Mutability (static, constant, extendable, mutable)
(Igor) Insertable, deletable, updateable?
(SteveG) xsd:default only works for simple types, but many properties will be complex types, so we need another mechanism.
(TomM) Schema defaults are for the use of the schema processor, it is not present in an instance document, but is inferred in the PSVI (post-schema validation infoset) at the client.
Action: This meaning of ‘default’ use of needs to be elucidated. Need a new issue on the list (MartinC)
(DaveS) Do we need a facility for data in the WSDL?
(Igor) No – the client only needs one round trip to get the value - it should be the same as a constant (unchanging) value set at service initialisation.
(DaveS) But it may be useful to be able to specify this at design time. The list seems to be:
§ Insertable:bool
§ Updateable: bool
§ Deleteable: bool
§ Readable: bool
§ Initial Value(s): <any>
§ Constant: bool
§ ValidValue: <any> (??)
Action: TomMaguire – write a proposal. – including how to get these values which was not discussed.
Issue 21 Splitting SetResourceProperties
(IanR) A proposal was published by Steve to introduce set/update/delete methods:
http://www.oasis-open.org/archives/wsrf/200407/msg00065.html
Proposed: to accept this as the text:
(except for a few small typos to be noted to SteveG) No objections
Review New issues since last telecom
(IanR) Proposed: The 2 issues raised earlier in the meeting should be added to the issues list in ‘Open’ state.
Proposed: 58, 59 and 60 can be moved open. (No objections)
Action: (Bryan) 58, 59 and 60 can be moved open. (No objections)
(IanR) Issue 57 looks like a valid issue
(SteveG) The specs should be ‘ref’ing the lifetimes – we need a specific example of what is going wrong
Action: Sam Meder to clarify.
(IanR) 56 looks valid (No Objections)
Action: (Bryan) Move 56 to ‘Open’
(TomM) Clarification of issue 57: both RL and SG specs need to use ‘ref’ to the definition from the RL spec
Action: (Bryan) Move 57 to ‘Open’
WSDM requirements (William V)
(Slides are on WSRF list:
http://www.oasis-open.org/apps/org/workgroup/wsrf/download.php/8283/)
§ WSDM is an early adopter of WSRF
o Standardized on WS-RP for accessing properties
o Uses WS-Addressing for manageability endpoints
o WSDM had requirements it was planning to meet on its own but are now best passed to WSRF (and WSN)
Already-communicated requirements
§
WSRF to define a topic for people to register for
notifications on value change affecting any property (or at least any property
for which notification is available ) without having to register for each one
- This is WSRF issue 55
§ Query list of available props (issue 9)
§ Discovery of EPR when you have the WSDL (issue 47)
o Not yet finalized by WSDM
§ Completeness of the EPR (issue 46)
o Retrieve the complete WSDL, know which service/port to use.
§ From WSDM MUWS requirements doc: (See url)
o Discovery of manageable resources through Web Services discovery mechanisms
(IanR) These are general
requirements, not necessarily for WSRF
(WilliamB) yes, but we need a response from WSRF.
o Access to aggregations of manageable resources, including invoking operations on several resources in one operation.
o Variety of resource types (logical/physical/long-lived/transient etc)
o
Discovery of relationships
(Anish) Such as?
(William) For example, dependency of a resource on a backup service.
o Modular approach to capabilities. Allows discovery of manageability capabilities.
o Versioning of WS-Resource endpoints
o Access to “attributes” (read and/or write)
o Meta-data introspectable at design time and run time.
(Abdeslem) How do you expect the logical/physical distinction to appear?
(steveG) It’s more about granularity than logical/physical
(SteveG) Is manageability capability a portType
(William) It could be – or an operation.
(Anish) What needs to be said about versioning?
(William) we need advice on what constitutes a new version of a WSRF resource.
Timeline
§ WSDM Targetted for Oct/Nov 2004
§ Doesn’t necessarily require a final WSRF specs, but needs answers to these questions.
(DaveS) We should consider which requirements should be issues.
-
(DaveS) Discovery is excluded by the charter. A
WS-Resource is a WS and that’s it,
(William) But we need to consider how to go from WSDL to EPR – which is issue
47.
-
(IanR) Invoking operations on aggregations is new, isn’t
it? Is this a
(SteveG) We could have an iterative operator that applies an operation to a
group of resources.
(William) Will this be addressed by WSRF this year?
(DaveS) we can have an open issue to record this.
Action: (Bryan) record new issue.
-
Relationships?
(IanR) To much is unknown about this.
-
Modular approach?
(williamB) this is a problem in WSDL 1.1, where namescopes are lost in
cut/paste aggregations. This is issue number 1.
Action: (Bryan) Record WSDM’s interest in this issue.
(William) Is there a normative definition of the cut/paste operations.
(SteveG) No
Action: (Bryan) Add this requirement to issue 1.
-
Versioning?
We have ways to vary the Resource Properties dynamically, and to do introspection.
Anything else is a general Web Services issue.
(Bryan) Would changes of operations require changes to EPRs?
(Martin) Only incompatible changes (removal of operations) are significant.
-
Introspectable meta-data?
(Ian) Issue was raised yesterday.
(Bryan) It will be issue 61.
WSN requirements (Peter Niblett)
Sildes are here:
http://www.oasis-open.org/apps/org/workgroup/wsrf/download.php/8284
§
Subscription Lifetime
(TomM) Changing the termination time of a subscription relative to the time at
the subscription manager is hard (chatty)
(DaveS) We need a way to use relative time
(SteveG) This is issue 19.
§ Summary chart
(AlanW) What is the status of the issue to separation of WS-N from WSRF?
(PeterN) This is on the agenda for tomorrow
WS-Remote Portlet Requirements/Use cases (Rich Tompsom)
Slides are here: http://www.oasis-open.org/apps/org/workgroup/wsrf/download.php/8301
§
Proposed leveraging of WSRF (Foil 15)
(SueM) Are the reference properties describing ‘customisation
records‘standardized and obligatory for clients?
(RichT) No, the semantics are defined and the definition is available – it
allows the client to know the hierarchy of the portlets.
(SueM) Why are these things in EPRs, rather than explicit parameters?
(RichT) Because this information is owned by the producer, not by the client.
(PeterN) Isn’t this an optimization –to avoid the need for the client to make
enquiries about resource properties?
(RichT) Yes.
(DaveS) Couldn’t this be done with WS-Context?
(MartinC) Yes.
(MartinC) Are these ref props needed for the client to address the WS-Resource?
(RichT) Yes.
(TimB) So, they identify the particular customization within a tree, but that
addressing info could be kept separately from the info needed by the client?
(RichT) Yes.
(TimB) Is the WSRF statement that refprops are ‘Opaque’ too strong - really
they are ‘read only’?
(RichT) Well, for the general user (passed an EPR from somewhere) they would be
opaque, but if a particular client knows what the semantics are, what’s wrong
with using that information?
(Anish) But a client can’t manipulate the EPR.
(MartinC) No – that would violate WS-Addressing.
(DaveS) So this is not illegal, but it could also be done other ways.
Document Management Proposal (Martin Chapman)
This was published to the list
here:
http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200407/msg00106.html
(IanR) we could, periodically, rev all the working drafts, but the suggestion is to make it more
(AlanW) We need to limit the frequency of working drafts.
(MartinC) Once per month would be the right sort of frequency.
(IanR) Could we have an editor’s
draft proposal.
(DaveS) Proposed: We need an editor’s drafts folder in which have a file
name appropriate to the next anticipated working draft level and a letter
suffix ‘-a’, ‘-b’ (etc) in the file name. Periodically, we create a set of
working drafts in a working drafts folder which contain text agreed by the TC
and is suitable for wider review.
(no objections)
(Bryan) We should move all the issue to closed at the same time?
(no objections)
Implied Resource Pattern (Steve Graham)
Some terminology was defined in
the initial submissions (in particular the Whitepaper), which defines
fundamental concepts and which needs some clarification to figure out what is
legal in WSRF and what is not. We need further clarification on what the
‘implied resource pattern’ is and how it can be embodied, for example in terms
of WS-Addresses. For example, can the resource properties be used freely,
according to the WS-Addressing specs, or does WSRF restrict its use? We need to
describe the patterns abstractly, by building a normative spec with
non-normative parts describing the implied resource pattern and its uses.
(AlanW) Which is the normative part?
(SteveG) The embodiment in terms of WS-Addressing would be normative, or an embodiment using a plain SOAP header, or WS-MD.
(Anish) So we don’t restrict the embodiments, but we specify particular embodiments?
(SteveG) Yes.
(MartinC) So what is at the
higher level?
(SteveG) We need to discuss that.
(MartnC) Do we need to formalize the notion of a ResourceID and map that? Or do we describe a ResourceID as a concept, which doesn’t help interoperability.
(MartinC) What is the meaning of ‘implicit’ – being in the header can be called ‘explicit’. Are there more shades of interpretation about what is implicit and what is explicit?
(PeterN) We need to discuss the concepts and clarify them.
(SteveG) Yes, we need to separate out what is independent of WS-Addressing.
(MartinC) The current spec says nothing more than WS Addressing, the client doesn’t know the difference between WS and WSRF.
(SteveG) True, at the portType level.
(MartinC) It’s unclear what is meant by a Web Service. One could create a port for each property document. The client looking at the point (or even the EPR) can’t tell. Should it be able to?
(GlenD) WSRP as a pattern is extremely usefully. The key to what makes WS specs useful is that they only fine wire protocols. So, this problem of knowing where the message goes should be factorable out, like security. The patterns of how to get and set are useful, but we really need to deal with is how to pass around EPRs.
(MartinC) Agreed.
(SteveG) I don’t think so: everyone can do their thing and we won’t be able to interoperate – we need to come up recommended embodiments.
(MartinC) Using www and http as an example: the client says get/post for a document, and the documents have global URLs. The analogy in WSRF is Web Services for get/post and a Resource Property document is the same as a web page, and the globalname is the thing inside the EPR. There is no definition of the header on the wire, so why should we be codifying it?
(Anish) There might be an intersection between Glen’s point and the abstraction proposal. In the context of SOAP the implied resource pattern says that the disambiguator is not in the soap body. We should not say where things go in the message – could be header or body.
(DaveS) What are the properties necessary in disambiguation? We need to identify these – eg that it should be provided by the service, not the client. This gives a place to judge which embodiments work.
(GlenD) Why is this aspect different from security? Why can’t it be factored out.
(SteveG) We are factoring out, maybe we need some re-factoring.
(MartinC) We need to separate out how to pass around the references and how to encode them on the wire. There might be out-of-band means to get them. It’s up to the server to choose the disambiguator, but it may be Ok to code them in the body – as BPEL does with correlators – in fact, they could be anywhere in the SOAP envelope.
(Anish) If this abstraction goes ahead, I suggest we pick a different name than ‘implied’ which has caused confusion.
(DaveS) If we separate out, what do we do about existing references to the WSRF embodiment – they should refer to the concept.
(Igor) ‘Singleton resource pattern’ and ‘implied resource pattern’ aren’t fundamental, only ‘resource’ is necessary.
(SteveG) Maybe.
(SueM) Is it consistent with the implied resource pattern to expose as an explicit parameter to an operation (i.e. in the SOAP body) the same disambiguation information that is in the header generated from an EPR?
(IanR) It is not inconsistent.
(Anish noted during the break) In the modeling resources paper, section -- 3.2 says: "By implicit, we mean to say that the requestor does not provide the stateful resource identifier as an explicit parameter in the body of the request message.” Perhaps this needs clarification.
(MartinC) (Takes up the pen and whiteboard and produces….)
Where are the resources – are they in the application level or in the web service level? If in the WS level it’s for us Middleware people, if in the Application layer, we ned to make it more obvious.
(MartinC) We need a model (abstractly) of the properties that flow on the wire to achieve interoperability – so that vendors can interoperate between embodiments (or with multiple embodiments)
(IanR) We’ll describe the implied resource pattern and what it means to satisfy it and some embodiments, what else is needed?
(Anish) The suggestion was a way to define the pattern – for example to define references abstractly.
(DaveS) We might need to do this.
(AlanW) How do we decide which are the embodiments.
(SteveG) The first order selection is whether people are willing to write them.
(IanR) Proposal: We will work on producing a new document that describes the implied resource pattern, what it means to satisfy the implied resource pattern, and certain embodiments of the implied resource pattern. We will also move the definition of WS-Resource from the state paper to this document. We will also address interoperability issues.
(No objections)
Action: Igor, Anish and SteveG.
(Anish) Can we discuss the single Resource Pattern?
(SteveG) The Single Pattern derives from a coupling between the implied resource pattern and WS-Addressing. Some people observed that a URL is a complete reference and wanted to treat view this as an EPR, which is fine.
(MartinC) So, the single pattern is what happens when there are no reference properties?
(SteveG) Yes.
Next face-to-face meeting
(IanR) Proposed: to meet 26 & 27th October in Cupertino, California hosted by HP.
(No Objections)
Priorities for next three months
(Anish) We should accelerate the requirements document so that it doesn’t produce requirements after the spec is finished.
(IanR) We should review it at the October meeting.
(SamM) We need something for Renewable References in short order, and/or a second-level naming scheme that gives permanent name for resources. It’s needed because we need to apply security policies to EPRs, which is kind of an identity.
(IanR) It’s out of scope to deal with identities.
(DaveS) Identities are needed, but we need to find out who is doing them. Maybe it’s WSDM.
(William) WSDM 1.0 will develop identity mechanisms from what is present in WSDM 0.5. The identity is associated with a real resource, and two EPRs can be use to query the id and the results can be compared.
(IanR) Should WSRF be doing something more general?
Action: (Sam) Raise a new issue to describe this.
(AlanW) We need to work on the non-normative ‘Usage notes’ document.
(SaveS) We should put that on the agenda.
(DaveS) The priorities are the new abstraction document and the Resource Properties document.
(DaveS) We also need to schedule an WSRF interop.
(AlanW) There are two kinds of interop: closed-door between vendors, and a show-case.
(DaveS) This would be internal business.
The agenda items are:
- Requirements document
- App notes document
- Schedule for the interop
Discussion of Issue Prioritisation
Action: (Chairs) upload new priority list to web site.
Meeting closed: 5:00pm.
Summary of actions
(Bryan) Re-categorize issue 48 as an application note
(AlanW) Create an issue to discuss the creation of a ‘Usage Notes’ (Primer) document.
(SteveG) Propose text to resolve issue 4
(MartinC) Raise a new issue to address Schema discovery on a dynamic property, including the cardinality within the RP document.
(TomM) Write resolution for issue 10.
(MartinC) Raise an issue to elucidate the meaning of ‘default’ to (separate this from issue 10).
(Bryan) Move issues 56 through to 60 to ‘open’ state.
(Bryan) Move new issues from the meeting to ‘open’ state.
(Bryan) Raise new issue to describe requirement for aggregation operations.
(Bryan) In issue 1, record WSDM’s interest and add the requirement to normatively describe the portType aggregations process.
(Igor, Anish and SteveG.) Create new document to abstractly describe the implied resource pattern and what it means to satisfy it (etc).
(Sam) Raise a new issue to consider an identity mechanism.
(Chairs) Upload new issue priorities list to web site.