[Requests] Comment on WPS 14-065

Daniel Nüst d.nuest at 52north.org
Tue Sep 30 05:56:08 EDT 2014


PART A


1. Evaluator:
         Daniel Nüst d.nuest at 52north.org

2. Submission: WPS 2.0, 14-065


PART B

1. Requirement: Add XML Schema annotation for the attribute 
"transmission" of the element definition OutputDefinitionType.

2. Implementation Specification Section number: XML Schemas

3. Criticality: Minor

4. Comments/justifications for changes: When looking at the schemas 
only, the semantics of the transmission attribute are not as well 
described as of other attributes or elements.


PART B


1. Requirement: Add correct annotation for element BoundingBoxData

2. Implementation Specification Section number: XML Schemas

3. Criticality: Minor

4. Comments/justifications for changes: The element definition of 
BoundingBoxData in dataTypes.xsd seems to be copy and pasted from 
ComplexData.


PART B

1. Requirement: clarity, friendly to non-WPS experts

2. Implementation Specification Section number: iii. Preface

3. Criticality: Editorial

4. Comments/justifications for changes: Clarify what "different 
architectures" are - different from what? From what WPS 1.0 supported? 
Then the previously supported ones should be mentioned. Or: "... to 
specify a WPS in different architectures such as REST" > "to specify a 
WPS in different architectures, such as REST or SOAP".



PART B

1. Requirement: Add missing comma after "SensorML" in "e.g. those 
defined in SensorML, and to execute them on a WPS server" to close the 
relative clause.

2. Implementation Specification Section number: iii. Preface

3. Criticality: Editorial

4. Comments/justifications for changes:


PART B

1. Requirement: Clarify how the transition is smoothed by the 
conformance class. Is it "similar to" or "effectively the same as" WPS 1.0?

2. Implementation Specification Section number: iii. Preface

3. Criticality: Editorial

4. Comments/justifications for changes: the preface should be 
understandable to people unaware of previous standards


PART B

1. Requirement: Define "WPS server" in Terms and Definitions

2. Implementation Specification Section number: 4. Terms and Definitions

3. Criticality: Editorial

4. Comments/justifications for changes: The term "WPS server" is used 
throughout the document but not defined. A "Web Processing Service 
server" could also simply be called "WPS", so using "WPS server" seems 
deliberate and should therefore be explained, e.g. as an implementation 
instance of WPS..


PART B

1. Requirement: Clarify potential typo in "covered nor restricted by 
this specification as long as they do not alter or change or the 
semantics of other job control capabilities."

2. Implementation Specification Section number: 6.2

3. Criticality: Editorial

4. Comments/justifications for changes: The last "or" seems to be 
superfluous.


PART B

1. Requirement: More precise definition of 
http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process/input-identifier

2. Implementation Specification Section number: 6.3

3. Criticality: Minor

4. Comments/justifications for changes: Each input of a process shall 
have a unique identifier to distinguish the input from all other inputs 
_of the process_. Such a distinction does exist for nested inputs and 
for ../output-identifier.


PART B

1. Requirement: GetResult must provide JobID in UML sequence diagram

2. Implementation Specification Section number: 6.5

3. Criticality: Minor

4. Comments/justifications for changes: The operation "GetResult" should 
be shown as "GetResult(JobID)" in the UML sequence diagram, as a client 
can only request the result for a known job.


PART B

1. Requirement: Clarify behaviour of GetResult when job is not executed yet

2. Implementation Specification Section number: 6.5

3. Criticality: Major

4. Comments/justifications for changes: The Process Execution section 
should contain requirements that define what happens when "GetResult" of 
a job is requested without the job being finished, e.g. if a client 
calls GetResult without checking job status beforehand.


PART B

1. Requirement: Exception behaviour for non existing job ids

2. Implementation Specification Section number: 6.5

3. Criticality: Minor

4. Comments/justifications for changes: It seems obvious, but shouldn't 
there be a requirement that specifies that the "service shall return an 
exception if the client has specified an invalid job id." ?


PART B

1. Requirement: Consistent cardinality in Figure 5

2. Implementation Specification Section number: 6.5

3. Criticality: Editorial

4. Comments/justifications for changes: To clarify that output servers 
can also be multiple ones, the third column from te left in the diagramm 
should be titles "Result Data Server(s)" instead of "Result Data Server"


PART B

1. Requirement: Clarify requirements 
http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/data-transmission/output-mode 
and ../output-mode-per-process-offering

2. Implementation Specification Section number: 6.6

3. Criticality: Minor

4. Comments/justifications for changes: "The service shall deliver the 
output data by value, by reference or in both modes." would imho be more 
clear stating "The service shall deliver the output data by value, by 
reference or in one of these modes." It is not meant that a process 
output provides both modes at the same time, is it? The 
../output-mode-select requirement also does not explicitly state that 
only one mode at at time for each output is supported.

The requirement ../output-mode-per-process-offering has the same text as 
the requirement above.


PART B

1. Requirement: "Next poll" behaviour for to many polling requests

2. Implementation Specification Section number: 6.7

3. Criticality: Minor

4. Comments/justifications for changes: In this section a requirements 
states that the "The Service may suggest a polling time for the next 
status check". However it is not clearly defined the semantics of this 
in a requirement, only in the text as a "maximum time before next poll 
should be made". What about a dual for this requirement defining the 
minimum amount of time that should pass before requesting the status 
again? Is this out of scope, or just assumed that a client may poll as 
much as it wants?


PART B

1. Requirement: "Running" status for synchronous requests does not exists

2. Implementation Specification Section number: 6.7

3. Criticality: Minor

4. Comments/justifications for changes: In Table 3, a footnote states 
that "Accepted" status is only defined for asynchronous execution. Is 
this not also the case for "Running"? How can a client be informed a 
process is running in a synchronous mode, when the direct response is 
either "Succeded" or "Failed".


PART B

1. Requirement: Undefined job expiry time

2. Implementation Specification Section number: 6.7

3. Criticality: Minor

4. Comments/justifications for changes: Clarify if it is possible to 
declare an indeterminate time for job expiry, i.e. "never". This might 
also relate to the service model.


PART B

1. Requirement: Clarify components and subsections

2. Implementation Specification Section number: 7

3. Criticality: Editorial

4. Comments/justifications for changes: The introductory text to section 
7 breaks down the native process model into three numbered components, 
but there are five requirements classes and five subsections. The three 
components should be related to the five requirement classes.


PART B

1. Requirement: Add reference to Table 5 in requirements

2. Implementation Specification Section number: 7.1

3. Criticality: Editorial

4. Comments/justifications for changes: Table 5 is not referenced from 
http://www.opengis.net/spec/WPS/2.0/req/native-process/model/description-type/metadata-simple-xlink, 
but it (or one of the other requirements) should mention it, because it 
defines/explains the terms, e.g. "title".


PART B

1. Requirement: Data element versus IOData element can be confusing

2. Implementation Specification Section number: 7.2, XML Schemas

3. Criticality: Minor

4. Comments/justifications for changes: On the first look at the schemas 
it was confusing to see a "Data" (in wpsCommon.xml) and a "IOData" 
element. The latter could be renamed to "IODataDescription" or 
"DataDescription", because it is used for describing data instead of 
wrapping actual data. The "Data" element can be used for input and 
output data ("IO") as well, right?


PART B

1. Requirement: Remove erroneous footnote

2. Implementation Specification Section number: 7.2, Table 6

3. Criticality: Editorial

4. Comments/justifications for changes: The "Definition" column of the 
property "maximumMegabytes" has a footnote "a" that does not belong there.


PART B

1. Requirement: Remove errorenours footnote

2. Implementation Specification Section number: 7.2, Table 6

3. Criticality: Editorial

4. Comments/justifications for changes: The "Definition" column of the 
property "maximumMegabytes" has a footnote "a" that does not belong 
there afaics.


PART B

1. Requirement: Clarify inheritance rules and give examples

2. Implementation Specification Section number: 7.5.4, Table 21

3. Criticality: Editorial

4. Comments/justifications for changes: Please elaborate on what 
"Inherit and Extend" and "Inherit and Restrict" means, especially in 
practical terms with an example. If I see it correctly, only elements 
(0..*) can be "E", while fields such as "Title" must be overriden. What 
does restriction/extension of a multiplicity mean?


PART B

1. Requirement: Add example with dimensions for BoundingBox Plain Text 
Encoding

2. Implementation Specification Section number: 8.2

3. Criticality: Editorial

4. Comments/justifications for changes: Please add an example for usage 
of the "dimensions" part of the BNF schema. If lc_coords are both at 
most two dimensions, this must be only for one-dimensional bounding 
boxes (lc/uc_coords have one dimension)?


PART B

1. Requirement: Clarify inheritance rules and give examples

2. Implementation Specification Section number: 7.5.4, Table 21

3. Criticality: Editorial

4. Comments/justifications for changes: Please elaborate on what 
"Inherit and Extend" and "Inherit and Restrict" means, especially in 
practical terms with an example. If I see it correctly, only elements 
(0..*) can be "E", while fields such as "Title" must be overriden. What 
does restriction/extension of a multiplicity mean?


PART B

1. Requirement: Add missing spaces in text "sections 9.12and9.13"

2. Implementation Specification Section number: 9.1

3. Criticality: Editorial

4. Comments/justifications for changes:


PART B

1. Requirement: Remove unused footnote "a" and type "Any. Value" in 
column "Data type .."

2. Implementation Specification Section number: 9.2, Table 23

3. Criticality: Editorial

4. Comments/justifications for changes:



PART B

1. Requirement: add XPath to references or describe what is meant by 
"../Reference/@href"

2. Implementation Specification Section number: 9.2, Table 26

3. Criticality: Editorial

4. Comments/justifications for changes: Table 26 uses a relative 
description of the location of an attribute. While being relatively 
clear, the used syntax should nevertheless be described.


PART B

1. Requirement: reference Tables from requirements

2. Implementation Specification Section number: 9.4

3. Criticality: Editorial

4. Comments/justifications for changes: The tables 29, 30 and 31 should 
be referenced from the text describing the requirements in section 9.4.


PART B

1. Requirement: Rephrase footnote b of Table 29

2. Implementation Specification Section number: 9.4

3. Criticality: Editorial

4. Comments/justifications for changes: The last part "compliance with 
the abstract process model has to be ensured compatibility with the WPS 
protocol" seems to be missing some content - at least I don't understand 
it.. "has ensure compatibility", "has to be compatible with" ?


PART B

1. Requirement: Add missing footnote reference (or remove footnote)

2. Implementation Specification Section number: 9.5, Table 32

3. Criticality: Editorial

4. Comments/justifications for changes: The footnote "c" is never used 
in the table.


PART B

1. Requirement: Consistency between schemas and spec, also unnecessary 
semantics

2. Implementation Specification Section number: 9.5, XML schemas

3. Criticality: Editorial

4. Comments/justifications for changes: Footnote d of Table 32 says 
about the PecentCompleted field that "This value is informative only 
without any accuracy guarantees", whereas the schema annotations says 
"This value is expected to be accurate to within ten percent.".

Imho the "within ten percent" is an unnecessary statement. If there is a 
clear expectation, then this should be stated as a requirement in the spec.

Not to take a sledgehammer to crack a nut, but the "precision" of the 
percentage estimation could well be defined as an interval, e.g. "1-10", 
"11-50" if such a flexibility is desired.


PART B

1. Requirement: Requirement for footnote a of Table 37

2. Implementation Specification Section number: 9.7.2

3. Criticality: Editorial

4. Comments/justifications for changes: To me "Additional content such 
as separate code space and version attributes in the Identifier element 
are not allowed." sounds like a requirement that should be phrased in a 
requirement.


PART B

1. Requirement: Clarify what happens when raw and multiple outputs are 
requested

2. Implementation Specification Section number: 9.9.3

3. Criticality: Minor

4. Comments/justifications for changes: Add a status code that handles 
the case for requesting multiple outputs as "raw". Or is "TooManyInputs" 
intended for that? Then mention this usage somewhere.


PART B

1. Requirement: Fix incomplete sentence "Due to the additional 
complexity involved in input and output handling."

2. Implementation Specification Section number: 10.2

3. Criticality: Editorial

4. Comments/justifications for changes: May be "Due to the additional 
complexity involved in input and output handling of the Execute 
operation", or just remove the sentence because the footnote 9 also 
mentions a related issue.


PART B

1. Requirement: Add reference for character escaping in URLs

2. Implementation Specification Section number: 10.2.2

3. Criticality: Editorial

4. Comments/justifications for changes: For the sake of helping new 
readers, a footnote explaining or giving a further resource what 
"Comma-separated list of URL escaped character strings." means in Table 
50 would be helpful.


PART B

1. Requirement: Clarify 
http://www.opengis.net/spec/WPS/2.0/req/service/model/dismiss/response/status-dismissed

2. Implementation Specification Section number: 12.1.2

3. Criticality: Minor

4. Comments/justifications for changes: The text of the requirement does 
not seem to be related to the Dismiss operation, since the result of a 
Dismiss operation is not a process description. This seems to be a copy 
and paste error from section 9.8.2


PART B

1. Requirement: Fix requirement identifiers

2. Implementation Specification Section number: 12.1.3

3. Criticality: Major

4. Comments/justifications for changes: The requirement identifiers use 
"../get-status/.." instead of dismiss.


PART B

1. Requirement: support for optional/multiple process outputs

2. Implementation Specification Section number: 6.5, 7.4, 9.9.3

3. Criticality: Minor

4. Comments/justifications for changes: Optional outputs should be 
defined in a similar fashion to optional inputs. This would require 
"empty" or NULL outputs, or occurrence properties for outputs 
(minOccurs, maxOccurs for multiple outputs), which are not supported by 
the specification.
It might also require to define the required and optional outputs of a 
process in the Execute request, or to put an exception into the 
partially successful response document.

Consider the following use case for optional outputs: A process produces 
an output document, e.g. a PDF, and also provides access to the 
underlying processed data and a zipped version of the complete workspace 
used for the process. If the document creation fails, then the 
underlying data and the zipped workspace are still valuable outputs. 
However, the WPS cannot communicate both the exception, which occurred 
during document creation, and return result data/the workspace.

Arguably, this could also be realized by having several (chained) 
processes, so feedback by the SWG is highly appreciated.



-- 
Daniel Nüst
52°North Initiative for Geospatial Open Source Software GmbH
Martin-Luther-King-Weg 24
48155 Münster, Germany
E-Mail: d.nuest at 52north.org
Fon: +49-(0)-251–396371-36
Fax: +49-(0)-251–396371-11

http://52north.org/
Twitter: @FiveTwoN

General Managers: Dr. Albert Remke, Dr. Andreas Wytzisk
Local Court Muenster HRB 10849


More information about the Requests mailing list