[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]