This document summarizes the significant changes made to the WS-RF draft specifications since Public Review 01 and also enumerates those public review comments which did not lead to changes in the specifications.

Issue WSRF110: BaseFaults validation

If you extend the BFType in another namespace (as we do) and add extra elements in that extension, then the schema that does the extension (e.g. WSN) violates the Unique Particle Attribution constraint as it becomes non-deterministic. This is because BaseFaultType ends with

<xs:any namespace="##other" minOccurs="0">.

So in the extended fault type you can't tell whether elements in an extended instance are to be validated by this <any> or by the elements in the extended type.

Specifications

· WS-BaseFaults

Resolution:

Move the xs:any extensibility element to be the first element of the BaseFault type, before the mandatory Timestamp element.

Issue WSRF122: Reference to WS-Addressing

We find that the current WS-addressing reference in WSRF-RP 1.2 CD is inappropriate. In its normative reference section on page 44, it refers to WS-addressing at "http://www.w3.org/TR/ws-addr-core." This address is always for the latest version and will be updated in the future. You should refer to "http://www.w3.org/TR/2005/WD-ws-addr-core-20050331" instead.

Specifications

· All

Resolution

No change to the reference. The reference is intended to point to the latest WS-Addressing 1.0 specification. The URL will continue to refer to WS-Addressing 1.0 even if, in the future, the W3C WG define a new WS-Addressing 2.0 standard.

References to the WS-Addressing namespace URI have been updated per the WS-Addressing 1.0 Candidate Recommendation draft.

Issue WSRF125, 126, 140: Wording for “Resource Properties Document”

Line 329. Shouldn't this start with "The complexType defining..."? It's not the resource properties document itself that's a global element declaration, is it?

Line 332. I don't understand the intent of requirement 2. Does this refer to the complexType that defines the resource properties document or an instance of the resource properties document? In either case, if requirement 1 is satisfied, how could you NOT refer to it by a QName?

Specifications

· WS-ResourceProperties

Resolution

These are now clarified in a simplified section 4.2 of WS-ResourceProperties (pr-02).

Issue WSRF127: Normative requirement for “Resource Action Pattern”?

Line 372 (and others) says, "The GetResourcePropertyDocument request message MUST follow the WS-Resource Access Pattern." I'm not clear what requirement this normative MUST imposes on the implementer. RFC 2119 says keywords "MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions). For example, they must not be used to try to impose a particular method on implementers where the method is not required for interoperability." I assume, then, that the requirement to follow the WS-Resource Access Pattern has something to do with interoperability. But the definition in WS-Resource isn't much help when it says, "An identifier of the resource MUST appear as part of any message to a WS-Resource to allow the WS-Resource to disambiguate the resource targeted by the message. We refer to this pattern of access as the 'WS-Resource Access Pattern'." Would it be possible to spell out more clearly what an implementer needs to do to satisfy the interop requirements of WS-RAP?

Specifications

· All

Resolution

Previously all message exchanges defined by the WS-RF specifications stated that the request messages "MUST follow the WS-Resource Access Pattern”.

These statements have been replaced by the requirement that any Web service that implements an interface that includes a resource properties document type declaration MUST comply with the definition of a WS-Resource in the WS-Resource specification. This definition has been simplified and the term “WS-Resource access pattern” has been removed.

Issue WSRF128: Multiplicity of response in the pseudo-schema for GetResourcePropertyDocument

Line 379. Shouldn't {any} be followed by a star ("*") since the resource properties document may be empty? This could happen (I think) if the resource properties document definition contained no resource property elements (per line 335) or because the resource property element(s) have minOccurs=0 and no values.

Specifications

· WS-ResourceProperties

Resolution

No change.

The response message to GetResourcePropertyDocument operation must always include the root element of the resource property document. Section 4.2 of the WS-ResourceProperties specification states that there must be a GED for the resource property document. As a result, the GetResourcePropertyDocumentResponse message must include exactly one child element. This means there should not be an ‘*’ after the {any} in the pseudo-schema and minOccurs should be “1”.

Issue WSRF129: Clarify description of the contents of the response to GetResourcePropertyDocument

Line 387 makes it sound like the contents of the response to GetResourcePropertyDocument must conform to the resource property document's schema. Is that the intent of "MUST correspond"? If so, what if the requestor doesn't have permission to retrieve a particular property that's required by the schema? Does the entire request fail?

In any case, I think it would be useful if the text was a little more explicit. If it's possible to fail because the requestor doesn't have permission for a particular resource property element, it might also be useful to define an "AccessDenied" fault.

Specifications

· WS-ResourceProperties

Resolution

No change.

WS-ResourceProperties does not specifically address security as this is a composable feature in the Web services architecture. WS-ResourceProperties does include a section describing the security risks that a developer will want to consider and if necessary provide protection against. When considering limited property access with the GetResourcePropertyDocument operation, a developer should not offer the operation to clients that do not have access to the entire resource properties document. Exposing this operation is optional and not providing it effectively removes the conundrum of returning partial resource property documents.

Issue WSRF130: Fault for operation not supported

It would be nice to define an OperationNotSupported fault for everything except GetResourceProperty.

Specifications

· WS-ResourceProperties

Resolution

No change.

WSDL defines the set of operations that are exposed by a resource. Examination of that WSDL will allow a potential client to avoid sending requests that are not understood by the resource. Furthermore, in more dynamic environments, such as those complying with the OGSA Basic Profile, properties are often defined to indicate which portTypes are supported by the resource. Thus, the TC has decided not to add the requested global fault.

Issue WSRF131: Correct use of MAY in GetMultipleResourceProperties

Line 566. I don't think the "MAY" there is used in the normative sense and thus probably shouldn't be capitalized.

Specifications

· WS-ResourceProperties

Resolution

No change.

Due to the precedence rules regarding normative statements (specification text takes priority over any pseudo-schema statements), the TC decided to retain the statement with the capitalized ‘MAY’ in order to emphasize the cardinality of the element.

Issue WSRF132: How does permission to access a property affect the response of GetMultipleResourceProperties?

Line 580-587. This text suggests that if the requestor asks for a resource property and that resource property element is not defined with minOccurs="0", it must be returned. But isn't it possible that the requestor doesn't have permission to access one or more of the properties he's asked for? In that case, must the WS-Resource fail the entire request?

Specifications

· WS-ResourceProperties

Resolution

The text (for this and other operations) has been clarified to indicate that if the response cannot return all of the properties that were requested, it must return a fault. This includes cases where, for security reasons, the resource cannot return values for all of the requested properties.

Issue WSRF133: Clarify the fault to be returned when a request specifies a QName that cannot exist in the resource property document

Line 590. Wouldn't it be better to specify that it MUST terminate with an InvalidResourcePropertyQName fault?

Specifications

· WS-ResourceProperties

Resolution

Modified the text to indicate that the InvalidResourcePropertyQNameFault message is to be returned instead of just saying ‘a fault message’.

Issue WSRF136: Clarify description of QueryExpressionDialect

Line 752. "When a portType includes the definition of the QueryResourceProperties operation, it MUST also include a reference to the wsrf-rp:QueryExpressionDialect Resource Property." Does a port type include a definition of QueryResourceProperties? Does a port type include a reference to the wsrf-rp:QueryExpressionDialect Resource Property? I'm not entirely sure what's intended here, but I'm guessing you mean that if a WS-Resource exposes the QueryResourceProperties operation, the resource properties document referenced by the portType MUST include wsrf-rp:QueryExpressionDialect as a resource property element. In other words, wsrf-rp:QueryExpressionDialect is a required resource property element on any resource properties document that may be accessed via the QueryResourceProperties operation. Is that right?

Specifications

· WS-ResourceProperties

Resolution

The sentence has been reworded to better indicate that the resource property document referred to by the portType must include a QueryExpressionDialect resource property element.

Issue WSRF137: Allow the MemberServiceEPR to be optional element in a ServiceGroup

Here are examples of why one might want to use a service group without providing an EPR for the members:

A company does not want to expose direct access to its printers from outside the firewall but it wants to externally expose a service group listing them for their supplier (e.g. Staples).
There is a well-known way that service EPRs are retrieved (like a directory) and the service group doesn't want to duplicate this information.
There is an evolving registry where the content may be available before the EPR.

Specifications

· WS-ServiceGroup

Resolution

MemberServiceEPR element has been made optional.

Issue WSRF139: Number of messages needed to retrieve the content of a service group

Section 5 of WS-SG says "The grouping and membership aspects of a ServiceGroup are only manifest in the linkage between a ServiceGroup and a ServiceGroupEntry". And section 5.1.2, in the description of /wsrf-sg:Entry/ServiceGroupEntryEPR says: "Endpoint reference as defined in [WS-Addressing] to the ServiceGroupEntry WS-Resource with which the entry is associated. This WS-Resource is the representation of the membership of the member in the group. Existence of this WS-Resource is the definitive test that the member is indeed part of the group. If the WS-Resource referenced by ServiceGroupEntryEPR is not available, the consumer MUST NOT assume that the Web service referenced by the @MemberServiceEPR is a member of the service group."

This means that in order to retrieve the membership of a 100-members service group, one has to send and receive 101 messages. One to retrieve the resource properties doc of the group and one to retrieve each entry. This is a huge cost and basically means that service groups of more than a handful of members cannot be used (or only in a very limited way) if one obeys the spec.

Specifications

· WS-ServiceGroup

Resolution

Remove the text above starting with the sentence beginning with “This WS-Resource is the representation …” (line 349 to 353). Make the content of the service group resource properties document the authoritative source of membership in the service group. Line 342, change “each entry of” to “each member of”.

Issue WSRF142: Name of WSDL message part

In the Public Review version of WS-BaseFaults, line 240 requires a specific name for the WSDL message part. The name of the WSDL message part does not affect interoperability and only needs to be consistent within the WSDL document in which it is declared. There is no reason for the specification to require that compliant services use a specific name for the part.

Specifications

· WS-BaseFaults

Resolution

Replace the text starting at line 240 with: “The WSDL part MUST have an element attribute and this MUST refer by QName to the element of this distinct fault as defined in step 2.”

Issue WSRF143: Context of XPath in QueryResourceProperties

Line 705 of WS-ResourceProperties states:

For XPath dialects, the namespace URI prefixes for the in-scope namespace declarations of the QueryResourceProperties element may be used in the XPath expression.

This means that any namespaces declared on the child element QueryExpression will be ignored for the purposes of XPath evaluation. It will likely to be common practice to declare those namespaces that do not appear elsewhere in the message on the nearest element to the XPath expression which is QueryExpression. In fact, a lot of tooling might do this by default. Therefore, in order to meet this requirement special cases will need to be made to assure that the namespaces are declared on the parent element instead.

Specifications

· WS-ResourceProperties

Resolution

Changed the text to indicate that the QueryExpression element is the context for XPath expressions from which XML namespace prefixes may be used.

Issue WSRF144: QueryResourceProperties does not have any dialect that is guaranteed to be supported

In order to increase interoperability there should be a required dialect for all WS-Resources that support QRP.

Specifications

· WS-ResourceProperties

Resolution

All resources that support QueryResourceProperties are now required to support the XPath 1.0 dialect. Other dialects may also be supported.

Issue WSRF147: Requirement for QueryExpressionDialect property

Section 5.4.2: Should the sample resource properties document include the "QueryExpressionDialect" property, to illustrate 5.4.1?

Specifications

· WS-ResourceProperties

Resolution

Changed the text to indicate that the declaration for the property MAY be included in the resource property document schema if the service supports only XPath and MUST be included if the service supports other dialects. MinOccurs is 0. Implementations are not required to indicate that XPath is a supported dialect because all implementations are required to support XPath if they support the operation.

Issue WSRF150: ResourceLifetime clarifications

- line 214: Is it allowed to have both the resource and the WS-Resource be destroyed upon a Destroy request? It seems there must be some cases where the existence of a WS-Resource is meaningless without any resources attached. If this is allowable what is the result of a requester message directed at a WS-Resource that has terminated? L476-477 refers to the WS-Resource terminating.

- Section 5.2: Under what circumstance does the "WS-Resource MUST provide a resource property element that provides the current time"? Only when it supports scheduled destruction, or any wsrf-rl operations? Or must all WS-Resource do this? Likewise for Section 5.3, the current termination time resource property.

Specifications

· WS-ResourceLifetime

Resolution

Replaced text with simpler text indicating that the Destroy message will have a response that is a DestroyResponse or a fault.

Clarified that the normative MUST is dependent upon support for scheduled termination.

Issues WSRF152, 158, 159, 160 and 161: Various incorrect references to other work

(1) WS-Resource 1.2 PR Draft 01

Page 11 contains a reference to [WSI Basic Profile 1.1]. But

page 7 defines [WS-Basic Profile 1.1]. We think it is typo.

(2) WS-ResourceProperties 1.2 PR Draft 01

Page 39 refers to [WS-Topics] but WS-Topics is pre-TC status.

I think it is inappropriate to normatively refer from this

document to pre-TC status specification.

(3) WS-ResourceProperties 1.2 PR Draft 01

WS-Topic's URL (wsn-WS-Topics-1.3-cd-01.pdf) on page 44 is

incorrect.

(4) WS-ResourceLifetime 1.2 PR Draft 01

Page 17 refers to [WS-Topics] but WS-Topics is pre-TC status.

I think it is inappropriate to normatively refer from this

document to pre-TC status specification.

(5) WS-ResourceLifetime 1.2 PR Draft 01

Since page 25 normatively refers to WS-I Basic Profile 1.1,

please add reference [WSI Basic Profile 1.1] to section 8.1.

(6) WS-ResourceProperties 1.2 PR Draft 02
Namespace "wsnt:" is defined nowhere in this document.

(7) WS-ResourceProperties, WS-ResourceLifetime, WS-BaseFault,
WS-ServiceGroup 1.2 PR Draft 02
Embedded multi-line hyperlinks do not work (Adobe Reader 7.0.5).

Specifications

· WS-ResourceProperties, WS-ResourceLifetime, WS-BaseFault, WS-ServiceGroup

Resolution

#1: fixed typo.

#2: Changed reference to WS-Topics to refer to version PR 01 in references section.

#3: fixed typo.

#4: same fix as #2.

#5: Line 791: Added reference to WS-I.

#6: Added wsnt into namespace prefix table.

#7: Regenerated PDFs to preserve hyperlinks.

Issue WSRF153: Error on line 501 of ServiceGroup

The “absolute time” form (whether computed from a duration, or contained within the request message) is used to initialize the value of the TerminationTime resource property of the Subscription resource.

Line 501 of version PR-01 contains the error. Line 494 of version wd-06 still contains the same error.

Specifications

· WS-ServiceGroup

Resolution

Fixed cut-and-paste error by changing reference from “Subscription” to “ServiceGroupEntry”.

Issue WSRF154: Use of MemberContentRule

Regarding Specification: WS ServiceGroup 1.2 wd06 I have three questions about MembershipContentRule and want more examples if possible.

(1) When a ServiceGroup WS-Resource wants its ServiceGroupEntry WS-Resources to support the operation(s) of ImmediateResourceTermination portType in their portType

- and Name of that portTypes are actually something like '{http://entry1.com/services}SomePortType',

- should it specify '{http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-ResourceLifetime-1.2-draft-04.wsdl}ImmediateResourceTermination' in MemberInterfaces attribute, or '{http://entry1.com/services}SomePortType'?

I think the former one is right because the names of portTypes are of great variety and it's meaningless to specify '{http://entry1.com/services}SomePortType'. But, I could not decide it.

(2) How can we get the information whether the specified service specified as a member implements that interface or not?

(3) I understand wsrf-sg:Content element is a reflection of an Entry web service. If so, I think the non-normative example of an Add request message in section 7.2.1 should be like this:

<s11:Envelope xmlns...>

<s11:Header>

...

</s11:Header>

<s11:Body>

<wsrf-sg:Add>

...

<wsrf-sg:Content>

<nsXX:YYYServiceProperties>

<wsn:TopicExpression>

wsrf-rp:ResourcePropertyValueChangeNotification

</wsn:TopicExperssion>

</nsXX:YYYServiceProperties>

</wsrf-sg:Content>

...

</wsrf-sg:Add>

</s11:Body>

</s11:Envelope>

According to the example in section 7.2.1, I'm afraid somebody might create such a request message as this:

...

<wsrf-sg:Content>

<wsn:TopicExpression>

wsrf-rp:ResourcePropertyValueChangeNotification

</wsn:TopicExperssion>

<tns:Prop001 ...>

ABC

</tns:Prop001>

<tns:Prop002 ...>

DEF

</tns:Prop002>

...

</wsrf-sg:Content>

...

But, you know, this is not correct and actually validation fails with the given XML Schema.

Specifications

· WS-ServiceGroup

Resolution

(1) MemberInterfaces refers to portTypes and not to operations. Lines 298-300 in PR02 indicate this. The ServiceGroup specification refers only to normatively-defined information in other specifications. For an interface name, therefore, only the most derived type is defined by WSDL 1.1, and this is the name that must be used in the MemberInterfaces attribute of the MembershipContentRule. In the example used in the comment email, it is the name http://entry1.com/services/SomePortType that should be used in the MemberInterfaces attribute. A small non-normative example has been added to the supporting AppNotes to answer the implied question about how to use the ServiceGroup MembershipContentRule for derived portTypes.

(2) This is an implementation detail and not an interface issue. Implementation details are out of scope for the specification.

(3) The contents of the Content element are associated but not identical to an Entry element – they have a type of any element and not exactly a resource properties document. Thus, both examples above are correct for the Add request message. However, if it is intended to have Content contain an entire resource property document, the wsrf-sg:RPDoc element should be used to wrap the resource property document element.

Issue WSRF156: Comments on WS-Resource definitions

Line 117 - use of the word logical is ambiguous, what does it mean?

Line 118 - A resource is identifiable but the specification does not tell implementers how to identify the resource. Normative references include URI - should it be a URI? If it is not by URI then the specification is in conflict with its normative references.

Line 122 - "A WS-Resource is a Web Service through which a resource can be accessed" does not correspond with the diagram at

Line 140. Line 122 defines a WS-Resource as being just a Web Service with some constraints; the diagram implies the WS-Resource is composed of the Web Service and the resource.

Line 140 - There is a semi-circle in the diagram that is not labeled, the thing "in front" of the Web Service.

Line 148 - Must an EPR for a WS-Resource contain ReferenceParameters, if not can an example be used which doesn't use ReferenceParameters?

Line 148 - This use of WS-Addressing EPRs is in direct conflict of with the W3C Web Architecture, attempts are being made by the W3C TAG to include in a statement in the WS-Addressing spec to this effect.

One proposed version of the statement is:

"Use of the abstract properties of an EPR other than wsa:address to identify resources is contrary to WebArch" For example, we note that WS-RF specification uses EPRs to identify information resources (such as for example experimental datasets in the Grid) which prevents hypertext links from being made to them.

http://lists.w3.org/Archives/Public/www-tag/2005Oct/0048.html

If ReferenceParameters are used in EPRs then any person who receives them probably should not share them with other people as the ReferenceParameters could contain client specific information, for example information that identifies the client to the server. A client cannot know the purpose of the ReferenceParameters, unless he is operating in a closed system where he has an understanding of the service's implementation. For Grid computing where sharing resources is important the use of ReferenceParameters by WSRF implementations could have serious consequences.

Specifications

· WS-Resource

Resolution

Line 117: This is logical as opposed to physical. The TC feels the text is clear. Primer wording to be made more clear.

Line 118: A resource identity is implementation independent and does not need to be a URI. The normative reference to URI is harmless. No change is necessary.

Line 122: Changed wording to: “A WS-Resource is a composition of a resource and a Web service providing access to the resource.”

Line 140: Removed the semi-circle in the diagram, since it is unnecessary and confusing.

Line 148: No, an EPR does not need to contain ReferenceParameters – this is just a non-normative example. WS-Resource references WS-Addressing and all other WSRF specs reference WS-Resource. WSRF does not mandate the use of the ReferenceParameters and leaves it up to the implementer to decide how to construct EPRs for their resources. For clarity, the example was changed to use a query parameter on the Address URI rather than a wsa:ReferenceParameter.

Issue WSRF157: UPA error in definition of wsrf-sg:ContentType

The ServiceGroup XSD (http://docs.oasis-open.org/wsrf/sg-2.xsd) has the following complexType definition:

<xsd:complexType name="ContentType">

<xsd:sequence>

<xsd:element name="RPDoc"

type="wsrf-sg:RPDocType"

minOccurs="0" maxOccurs="1" />

<xsd:any namespace="##any" processContents="lax"

minOccurs="0" maxOccurs="unbounded" />

</xsd:sequence>

<xsd:anyAttribute namespace="##other"

processContents="lax"/>

</xsd:complexType>

This does not validate because of a Unique Particle Attribution error.

Specifications

· WS-ServiceGroup

Resolution

Changed the extensibility element’s namespace attribute from “##any” to “##other”, which was the semantic intended in the spec.

Issue WSRF164: PR Comment: InitialTerminationTime element of Add operation should be nillable

It does not seem InitialTerminationTime element of Add operation of ServiceGroupRegistration portType in given XML Schema is nillable.

Specifications

· WS-ServiceGroup

Resolution

The “nillable” attribute was added to the InitialTerminationTime element of the Add operation.