[ogsa-wg] [ogsa-naming-wg] New Version of OGSA Naming

[Frank Siebenlist]

Excellent - we're almost there!

Just a couple of small issues:


1) Section 4 Endpoint Identifier Profile

<quote>
The EndpointIdentifier element MUST be included in the ENDPOINTREFERENCE
wsa:Metadata element. The schema for an EndpointIdentifier is included
in Appendix A."
</quote>

This is a little confusing because we could also have an EPI through the
wsa:Address of a Web Service Endpoint Address Profile or we could add
one in the reference properties.
Maybe it should be something like "When an EPI is added to the Metadata
element, then it MUST be according..."


2) Section 4 Endpoint Identifier Profile

We should be able to have 0,1 or more EPIs added to the metadata element.


3) section 5.1.3 Fault Types

<quote>
/naming:referral-epr

An EndpointReference, provided by the resolver INSTANCE, that references
an alternative resolution service. The referral-epr element contains
either a naming:EndpointIdentifierResolver and naming:ReferenceResolver
element, as defined is section 5.2.
</quote>

This is a little confusing... I believe this implies that we use the
exact same elements for the EndpointIdentifierResolver and
ReferenceResolver EPRs as we use in the EPR's Metadata element...


4)section 5.1.3 Fault Types

We should also add the option to return a referral EPI, i.e. an alias
that in turn can be resolved to an application-EPR.

In other words, the exact same
EndpointIdentifier/EndpointIdentifierResolver/ReferenceResolver trio
that we can add to a Metadata element could be returned as referral
information (including multiples).


5) section 6. Web Service Endpoint Address Identifier Profile

I don't believe it's clear enough that such an wsa:Address is a
full-fledged EPI that can be used with the resolvers that we defined.

Maybe we can change:

This profile restricts the “Unambiguous Web Service Endpoint Profile”
further, and defines the requirements placed on an EPR wsa:Address field
(IRI) to ensure that it is unique in space and time, and that it by
itself identifies the endpoint/resource.

to:

This profile restricts the “Unambiguous Web Service Endpoint Profile”
further, and defines the requirements placed on an EPR wsa:Address field
(IRI) to ensure that it is unique in space and time, and that it by
itself identifies the endpoint/resource, and can therefor be used as an
EPI with any of the defined resolver services.


6) Annotation of EPR with profile conformance claim URIs

In some cases, we can infer the profile conformance claim from the EPR
content, like:
if the Metadata section includes an EndpointIdentifier,
EndpointIdentifierResolver, or ReferenceResolver element, then it
conforms at least to the "Unambiguous Web Service Endpoint Profile".

However, we have no way yet to communicate any profile conformance claim
in the EPR.

I suggest to add another element to the EPR's Metadata section like:

…
<naming:profile-conformance-claim>
xsd:anyURI
</naming:profile-conformance-claim>
...

such that we could have an EPR like:

<wsa:EndpointReference
xmlns:wsa=”http://www.w3.org/2005/03/addressing”
xmlns:naming=”http://ggf.org/name”>
<wsa:Address>
http://tempuri.org/example_application/B94C4186-0923-4dbb-AD9C-39DFB8B54388
</wsa:Address>
<wsa:Metadata>
<naming:profile-conformance-claim>
http://www.ogf.org/naming/2006/08/naming-wsepai-pf
</naming:profile-conformance-claim>
</wsa:Metadata>
</wsa:EndpointReference>


That's all!
See you all in DC.
Regards, Frank.


David Snelling wrote:
> Folks,
>
> Sorry for the large posting. The OGSA-Naming site is not allowing me
> to post - maybe I just need to sign up as a GF member.
>
> Joel, Can you post both these documents in "Documents > Root Folder >
> Current Drafts"?
>
> What I have done:
>
> 1) Accepted all previous changes.
>
> 2) Rewrote major sections (lots of out of date stuff about
> WS-Addressing being pre standard etc.)
>
> 3) Reorganized the sections around the 4 specs outlined in the use
> cases document,
>
> 4) Added the missing sections that were my action items.
>
> 5) Separated normative and non-normative parts of each section, see
> subsections "Non Normative Discussion". These sections could probably
> be extended.
>
> 6) I removed the SOAP message examples. These could go back in an
> appendix, but they would be non normative (I don't like having too
> much of this is a spec) and I wanted to get this out sooner.
>
> 7) Asked Michel Drescher to do a new set of schema and WSDL.
>
> There are two documents attached:
>
> 1) draft-ws-naming-August-2006-1-ct.doc: This has all my changes
> tracked. This is provided for process reasons. I really expect folks
> top start with the clean copy.
>
> 2) draft-ws-naming-August-2006-1.doc: I have accepted all my own
> changes, since it is virtually a new document. People should start
> with this, and use the above to identify things they thought were
> there and went away.
>
> Enjoy!
>
> -- 
> Take care:
>
> Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
> Fujitsu Laboratories of Europe
> Hayes Park Central
> Hayes End Road
> Hayes, Middlesex UB4 8FE
>
> +44-208-606-4649 (Office)
> +44-208-606-4539 (Fax)
> +44-7768-807526 (Mobile)
>
>
>

-- 
Frank Siebenlist               franks at mcs.anl.gov
The Globus Alliance - Argonne National Laboratory