Notes from the
OASIS WSRF TC
Teleconference
20th March 2006
Agenda
See:
http://www.oasis-open.org/apps/org/workgroup/wsrf/event.php?event_id=7758
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=7758
The meeting was quorate.
Confirm minute
taker
Tim
Banks is taking the minutes.
Approve minutes of
Teleconference on 6th March
See:
http://www.oasis-open.org/committees/download.php/17028
There
were no comments on the minutes and no objections to approving them.
Action Review -
chair (DaveS)
(Ian) Post an
electronic ballot for people to vote the AppNotes as a committee
draft. Done
(Chairs) Agenda item
to decide on Public Comment for AppNotes. Carry to next Call
(Brian) Mark WSRF119
Re-resolved (back to MetaData Descriptor) Done
(Brian) Open
WSRF165, WSRF166, WSRF169-WSRF173 Done
Potential new
issues - Bryan
(DaveS) There was
one message..
(TimB) ...today -
about RMD here:
http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200603/msg00015.html
(IanR) I think we
should discuss whether this is an issue
(DaveS) There are
other RMD issues which will cover this, so no new issues yet.
WSRF/Microsoft
Convergence Document (Ian)
See (for example)
http://devresource.hp.com/drc/specifications/wsm/index.jsp
(TomR) This hasn't
been submitted to a standards body, so what shall we do with it?
(Ian) Right. For the
moment, this is just for information about a 'member submission'.
(KirkW) We welcome
this, but one comment in the paper says that WSRF needs to be
refactored to delineate functions beyond WS Resource Transfer. What
happens to the notion of 'WS Resource' in the refactoring?
(IanR) I think the
concept is implicit in WS Transfer. These are the things that can
consume Put and Get. The only difference is the presence of the RP
Document.
(Kirk) So it's an
issue of the WSDL. How can this be done to enable one to move forward
on the converged path.
(IanR) Right, so
it's not clear what kind of data will be got and put with WS
Transfer. One thing that may come out of the process is a clear
definition of the resource.
(Kirk) So, at the
present time, users don't know what to do.
(IanR) Well, the
worst that can happen is that the WSRF RP attribute on the portType
is ignored.
(Kirk) Ok.
(DaveS) What is the
timeline? When will WSRF be superseded?
(IanR) I don't think
WSRF will be completely superseded. The two will co-exist. Speaking
as IBM, we are implementing WSRF – we will add to it when the
new stuff comes out.
(DaveS) Please
can we switch Chairs for the meeting at this point to have Ian chair
the call? I'm in a taxi.
(Ian) Ok
(Lilly) How soon can
we see the initial version of WS ResourceTransfer.
(Ian) I honestly
don't know. I hope sooner rather than later.
(Lilly) We don't
have a WSRF implementation, so we might start with WS-RT.
(IanR) Well, I don't
think WS-RT should be an inhibitor to implementing WSRF.or WS
Transfer.
Issue resolution -
Chair
Issue WSRF165: Clarify uniqueness of RMD per
resource property
(TimB)
There are bits of the spec that are leftover from the time when we
had inheritance and a list of MDDs, and therefore potentially
overlapping property descriptors for a resource property qname
(IanR)
And we got rid of that technique.
(BryanM)
I think we need to resolve this to restrict it to one description of
a resourceproperty
(DaveS)
I second that.
(Ianr)
So the motion is to resolve the issue so that a resourceproperty
should have at most one property in a metadataDatadescriptor. Any
objections.
None.
(TimB)
So the detail of this is that we need to add a normative statement in
the spec.
(IanR)
I think we can leave the details to the editor.
(DaveS)
We could enforce this in the schema.
(TimB)
This is listed as an option in the proposed recommendation.
(Bryan)
This would require use of the xsd:key to enforce the constraint.
(DaveS)
I'm happy not to enforce it if it's difficult.
(TimB)
There's also the issue of the cardinality of the
MatadataDescriptorRef in the schema – this needs to be
maxOccurs=1.
Action:
(Bryan) move issue 165 to resolved as per the proposals in the
issue list.
(IanR)
There is a potential issue to deal with wrt the two ways to define
the qname and location of the MDD. It can be via an attribute on the
portType vs ResourceProperties.
(DaveS)
There's another twist: the schema and spec are at odds. The schema
points to the MDD, not the MDDref as implied by the spec. We could
use the resourceProperty to contain the metadata. In a dynamic
environment, the metadata can be updated along with the
resourceProperties.
(IanR)
What is the type of the metadata resourceProperty in the schema.
(DaveS)
It's the type of the MDD, not the URI thing. Which is how I want it.
(TimB)
I think it points to the MDDref type.
(DaveS)
Anyway, I want to raise the issue that it should point to the
MDDtype, not the MDDref type.
(IanR)
This would be a bad thing – because there are two copies of the
data which could be out of sync.
(DaveS)
That's why the precedence question is important: we may have two
anyway since we have two references.
(IanR)
There is a clear issue about which reference wins, but whether there
is also a copy of the MDD, then that's a different issue.
(DaveS)
I think this should be THE copy, and the URI is a way to get it.
Fundamentally, we need a way to have dynamic metadata. For example, a
property may change from Read-only to read-write as the state of the
system evolves. If it can be got beforehand, that's a bonus.
(IanR)
We have always had a requirement to separate metadata.
(DaveS)
I don't think so -the MD is separate, optional and the client can
cope without it.
(IanR)
But if it exists, it's accessible from the WSDL for the benefit of
design-time decisions, and it has always been our intention to
separate the documents because the authors of the RP and the metadata
might be different, and the lifecycle can be different.
(DaveS)
Right on both counts, but we have a discovery mechanism for the
metadata, why not use it?
(IanR)
The perfect discovery mechanism is an attribute on the portType.
(DaveS)
That only works for static metadata, and we need dynamic, because the
resourceproperties are dynamic. For the dynamic case, the direct
access is useful because the client may not have the WSDL, and
doesn't want to go via a third mechanism (besides schema and
getResourceProperties) to get it. It would be much neater to have the
option of putting the MDD in a resourceProperty
(IanR)
The spec says the RP is a MDDRef.
(DaveS)
Yes, but the schema is the other way. Either way, I need this as an
issue. I think that if the chairs disagree this has to be an issue!
(IanR)
The schema has a sequence of Anys.
(Bryan)
This is the extensibility point: the name in the refType is the one
that points to the MDD.
(IanR)
We have two issues – one is the order of preference to the MDD
-this is issue 173. and we have Dave's proposal that the MDD has a
“byValue” representation in the ResourceProperties.
(Bryan)
We might want to have both the byValue and the byRef
(DaveS)
Yes.
Action
(DaveS) Write up the issue to consider byValue resourceProperty for
the MDD and send to the list.
Issue WSRF173: Specify precedence order for
publishing RMD
(IanR)
The proposed recommendation is that the RO instance takes precedence
because the dynamic metadata should override the static.
(DaveS)
Yes.
(DanJ)
The other problem is that the wsdl URI is relative.
(DaveS)
Which is handy for design work.
(IanR)
I don't understand the problem here. A consumer of a deployed WS
Resource may wish to make design-time decisions, and will use the
absolute URI. Why do we need to be concerned here?
(DanJ)
The current spec allows for any URI.
(IanR)
So why do we need to say anything?
(DanJ)
The relative URI is no good for a deployed Web service with a
non-existent location for the WSDL.
(IanR)
Why would anyone do this?
(DanJ)
– Well, lots of people seem to do it.
(IanR)
But it doesn't work.
(BryanM)
The only way to do this is to use xmlbase. Without this, it's not
interoperable.
(IanR)
I still don't think we need to say anything.
(DaveS)
It's handy for packaging of applications to use relative URIs., but
it doesn't work.This came up today in the mailing list, but I don't
think it's an issue.
(IanR)
Right.
(DaveS)
However, this means that it makes more sense to have the
ResourceProperty version of the MDDref as the definitive one.
(IanR)
I think the scenario of dynamic updates is a motivating one.
(BryanM)
I think dynamic is an orthogonal issue – the target of the URI
could be dynamic.
(IanR)
Dave is suggesting dynamic on a per-WS Resource instance basis.
(DaveS)
Yes – that's possible.
(BryanM)
So the resourceProperty makes more sense, and the RP should be the
priority.
(IanR)
The per-WS Resource instance is described in the RMD spec – I
apologize for not realising this earlier in the discussion. I
withdraw my earlier objection.
(DaveS)
So lets vote.
(IanR)
Who seconded?
(Bryan)
I think issue should be resolved with the RP as the precedence
(TimB)
So this is as in the issue proposal?
(IanR)
Yes – any objections to this?
None.
Action
(Bryan) Move issue 173 to resolved.
Issue WSRF166: Make primer examples use complete
xsd/wsdl
(DaveS)
In the spec, we backed off from putting full examples: the reader
might assume the example (eg of reference parameters) shows the only
way of doing it. If it's for one person, why not just send them the
full samples privately? What does anyone else think?
(DanJ)
I think a lot of people want to see as many SOAP message exchanges &
XML examples as possible since the don't understand the spec the
first time. Concrete examples are very important.
(Kirk)
Maybe the first example could show the detail, then use the ellipsis
afterwards.
(TimB)
That's how it works right now.
(IanR)
Are the any objections to the principle of this – publishing
with hyperlinks? And is it feasible?
(TimB)
The hyperlinks have been troublesome, but it seems possible.
(DaveS)
Would we put these hyperlinks in OASIS space?
(TimB)
Yes.
(DaveS)
Good, so we have to ask OASIS to do it?
(IanR)
We can do that. So the Primer would remain as it is, but just with
the hyperlinks
(TimB)
Yes.
(IanR)
So are there any objections to resolving as proposed?
None.
Action
(Bryan) Move issue 166 to resolved as proposed.
Issue WSRF167: Correction
to the RMD schema
(IanR)
This is about the import which is missing .xsd of schemalocation
(TimB)
The second paragraph lists extensibility points where the proposal is
to move the <xsd:any/> to the start of the sequence.
(DaveS)
Should we split the issue? I thought these were two examples of
typos on issues already agreed.
(Timb)
I think we need to talk about the extensibility.
(DaveS)
Your'e saying we don't need extensibility, or that the extensibility
should be any-other.
(TimB)
I'm happy if it says any-other.
(DaveS)
So, the typo is to fix the xsd reference and add namespace ##other to
the <any> which should be at the start of the sequence.
(TimB)
I don;t like them being at the front – that's not needed to
satisfy the UPA constraint.
(IanR)
So there's a friendly amendment to leave <any> where it is but
add namespace ##other.
(DaveS)
Ok.
(IanR)
So Tim proposed the motion
(FredC)
I'll second it.
(IanR)
Any objections.
None.
Action:
(Bryan) Move issue 167 to resolved.
Issue
WSRF168: Do we know that all simple types are ordered sets?
(DaveS)
We need to clarify that only ordered types can have the range. There
are simple types that don;t have an order.
(IanR)
Could we declare that this is obvious?
(DanJ)
I think we need this. I was confused by it.
(IanR)
Do we need to discuss concrete text or the proposed recommendnation?
No-one
thought so.
(IanR)
So it's proposed by DaveS, and seconded by Dan to qualify the use of
ValidValueRange to apply to simple ordered types.
Action
(Bryan) Move issue 168 to resolved.
AOB
None.
Straggler Roll Call
– see Meeting record.
Closed
17:25
Next
telecon is in two weeks on 3rd April.
Summary of actions
(Chairs) Agenda item
to decide on Public Comment for AppNotes. Carried from 6th
March.
(Bryan)
move issue 165 to resolved as per the proposals in the issue list.
(DaveS)
Write up the issue to consider byValue resourceProperty for the MDD
and send to the list.
(Bryan)
Move issue 173 to resolved.
(Bryan)
Move issue 166 to resolved as proposed.
(Bryan) Move issue
167 to resolved as ammended.
(Bryan) Move issue
168 to resolved.
|