Re: rough draft using ws-addressing

[John Fuller <jfuller@wernervas.com>]

wd-asap-spec-02a.doc

The document location was corrected (thanks, Sameer)

I corrected the schema so that it validates, however the inserted 
schema snippets in the document still need to be edited.

In this draft stateType is represented using option 4) from the 
previous letter.
(This begs the question, should we do the same thing with Event?)

For the schema to validate, I created new groups: one for all resources 
that includes the key element,
and one for descriptive tags like name and description, and the other 
groups include these groups.
In this way when a choice needs to be made we don't run into ambiguity 
with overlapping elements in different groups.
This corrects the use of "groups" of elements, but will effect the 
inserted snippets in the document,
and we'll have to make sure the "sequence" aspect makes sense.

The schema was also corrected to use the correct quote symbols, 
correctly define and import the necessary namespaces
and use EndpointReferenceType not EndpointReference for the type of 
particular elements.


On Dec 7, 2004, at 11:49 AM, John Fuller wrote:

> <wd-asap-spec-02a.doc>
>
> First pass at adding WS-Addressing: EPRs are used to traffic URIs, 
> Keys are still URIs.
> 	Further wording or renaming may be necessary here.
> Added an EPR for instance presentation and an EPR for factories to 
> relate instances by service groups
> Added WSDL
> 	only up to port types (like wsdm), leaving the binding for 
> nonnormative specification.
> 	headers are removed since ws-addressing can deal with this in the 
> binding
>
> The advantage of what we have now is it is fairly minimal and people 
> can get going right away.
>
> Eventually it might be nice to produce an accompanying documents 
> showing how
> 	wsdl can be provided to use WSRF-RP to access the resource properies 
> as well,
> 	how factories and instances could be managed using a service group 
> concept WSRF-SG
> 	and how notification can happen using WSN, defining some topic spaces.
> Eventually the tooling to interact with our services in this way will 
> be more readily available.