OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: ResourceProperty comments from HP


I have done a critical review of WS-ResourceProperties. I am listing
several issues below, but most of them are editorial. I am listing one
more significant issue at the top of this list that the TC should
address. All comments are from the Public Review version.

Bryan


Discuss in TC
-------------

1. Line 706: The namespace context for the query expression should be
the QueryExpression element and not the QueryResourceProperties element,
otherwise all namespaces defined on the QueryExpression element cannot
be used in the expression.




Editorial
---------

2. Introduction talks about standardizing the means by which properties
are defined. We really are not specifying how a schema is defined, just
that there be a link to it from the WSDL doc - so we are not
standardizing the means the properties are defined. Also, the
introduction says that the resource property doc is a view on a
WS-Resource - it should be a view on a resource.

3. OGSI should not be mentioned in the intro - it is already mentioned
in acknowledgements.

4. I would remove the non-goal section, partly because we are moving
that direction, partly because it is not very relevant.

5. Line 162: The reference to RFC 2119 should not have a space (the
references section does not).

6. Line 163: this paragraph should be removed because there are no
references to infoset. In fact every use of brackets indicates one of
the references in the reference section and not an infoset property.
Also, the "[XML Infoset]" reference should be "[XML-Infoset]" to match
the reference section.

7. The SOAP 1.1 namespace is used. Since we only show the wsa:Action
header with no mustUnderstand, there is no need to be restricted to SOAP
1.1. Lets do what WSN did and use the prefix 's' to mean both versions
of SOAP.

8. Line 264 says "two" where it should be "three"

9. Line 323 talks of defining a resource-specific operation. We might
want to say that you SHOULD provide access to all of a resource's state
through the standard operations and you MAY define any other
resource-specific operations as you see fit.

10. I think we could remove the interface field from all of the
wsa:Action definitions since that interface will never be realized.

11. Line 389: The spec says "... comprise all of the resource property
values ...". It seems to me that the contents comprise only that portion
of the XML representation of the resource that the resource is willing
to give you. For security reasons it may not give you everything. The
client should be ready to take what it can get and not necessarily
expect to get everything. Also, this statement is repeated for every
message exchange, wouldn't it be better to just state it once and have
it apply to all message exchanges.

12. Line 394: we should add ', but other fault messages may be
returned'. Make a similar change to all other operations.

13. Line 488: change 'XML element' to 'XML element(s)'.

14. Line 496: double colons

15. It seems that the resource property document instance could be
placed once in section 3 and all operations refer to that instance
rather than repreating the instance for every operation.

16. Line 675: change "[XPath]" to "[XPATH]" to match the label in the
references section

17. Update all references to the namespace
"http://www.w3.org/TR/2003/WD-xpath20-20031112/"; to be
"http://www.w3.org/TR/2005/WD-xpath20-20050404/"; since that is the
latest version of the spec. The text could even say that a new dialect
URI will be added for future version of XPath 2.0 by using the namespace
of the XPath 2.0 specification.

18. Line 739: double colon

19. Line 878 and 884: add the prefix 'tns' to the resource property
document element to match the PRPD request. I would make the values in
the request different from the values in the previous instance.

20. Line 934 and 944 should be brackets "[]" rather than braces "{}" if
we are following the notations set out in section 1.2.

21. Line 1037: I don't understand this sentence or know how it is
associated with the name of the fault.

22. Line 1122: the following should be added to the sentence ", assuming
the resource properties document still validates against its schema".

23. line 1173: change InsertResourcePropertiesDocument to
InsertResourceProperties

24. line 1299: change UpdateResourcePropertiesDocument to
UpdateResourceProperties

25. line 1403: change DeleteResourcePropertiesDocument to
DeleteResourceProperties

26. line 1477: change "encapsulatethe" to "encapsulate the".

27. Section 6.1 seems to imply that WSRF-RP requires that Topics be used
even though Topics are now an optional part of WSN. The Topic property
should NOT be required. It should be optional to create a TopicSpace
document. Also, the Topic element has changed name to TopicExpression.
This section may require several tweaks to comply with the new WS-baseN.

28. section 6.2: is it acceptable to send a single
AnyResourcePropertyValueChange if PutResourcePropertyDocument is
processed?

29. line 1617: Add GetResourcePropertyDocument

30. The references section contains normative references to URI and
WS-Addressing even though they are never referenced.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]