validation status port

[Marisa DeMeglio]

I've implemented the validation status port on the dtbook and nimas validators. Just to recap:

* there's a new output port called "validation-status"
* it outputs validation status XML (http://code.google.com/p/daisy-pipeline/wiki/ValidationStatusXML)
* this port allows one to quickly determine whether validation succeeded or not

Use the "validation-status-port" branch of both the pipeline-scripts and pipeline-modules-common repos to test this out.

Our original thinking was that this port was required, because a validation job can succeed even if the validation itself produces errors. So now the web UI can show something to indicate that the validation failed.

I think this is pretty straightforward but let me know if it needs anything else to be more useful.

Marisa

[Jostein Austvik Jacobsen]

Looks good to me.

Several of the standard XProc steps often use the c:result element with a text node describing the result. I like using an attribute for the result as you've done with d:validation-status/@result better than having it as a text node as it seems easier to manipulate with XProc. I'm doubt there's anything to gain by using c:result instead though, so I'm happy with d:validation-status :)

Jostein

Marisa

--
You received this message because you are subscribed to the Google Groups "DAISY Pipeline Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to daisy-pipeline-...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Jostein Austvik Jacobsen]

I'm having a look at how to implement this in the Web UI and I'm starting to think this is something that should be handled mainly by the framework.

The way it's currently specified, the client has to check the contents of an output port to know whether or not the validation succeeded. However, when the client has access to the filesystem and chooses to set its own output directory for an output port (currently local mode), there is no way to get the contents of the output port through the Web API - the client has to remember which output directory it provided to the Web API and inspect the files in that directory (after having determined which port is the validation status port by checking the script XML). It's still achievable, but it complicates things for the clients.

Even when the client lets the engine handle the outputs (currently remote mode), which means that the XML can be retrieved through the Web API, it's not available directly through the job status XML. It's a two-step process where the client needs to iterate throught all the result elements and look for a result with the correct mime type; then retrieve that document.

To make things easier for the clients, the framework could provide the validation status directly in the job XML. Some suggestions:

1. Introduce a new "FAILED" job status for jobs that succeeds but has a status port signaling a failure (ERROR vs FAILED would be kind of like static vs dynamic errors, or compile-time vs runtime errors)
2. Introduce a new attribute or element containing the validation status
3. Inline the validation status XML in the result element

What do you think?

Jostein

[Jostein Austvik Jacobsen]

Also, it would be nice to be able to determine the validation status through the jobs listing (introducing a "FAILED" job status would allow that).

Jostein

[Romain Deltour]

Yes, this sounds reasonable to me. I like that clients don't have to parse stored output documents to have access to the validation results.

Javier, Marisa, (and others too) what do you think ?

Romain.

[Marisa DeMeglio]

Sounds good. So the fwk would identify that a script might FAIL (instead of just ERROR) because it has a port like this:

 <p:output port="validation-status" px:media-type="application/xml+vnd.pipeline.status">

and the output of this port is

<d:validation-status xmlns:d="http://www.daisy.org/ns/pipeline/data" result="error"/>

(see http://code.google.com/p/daisy-pipeline/wiki/ValidationStatusXML)

Marisa

[Romain Deltour]

RIght.

Should this be allowed for any kind of job btw, not necessarily validation ? What about just renaming the d:validation-status element into d:job-status ?

Romain.

[Jostein Austvik Jacobsen]

Yeah, there's no way to stop script authors from using the status port for non-validator scripts anyway (unless we introduce a way to declare that "this is a validation script").

Jostein

[Javier Asensio]

I'm not really convinced that the fwk should know about the internals of the script, in terms of the semantics of the results. IMO a failed validation doesnt seem appropriate as job status, the job itself didn't failed. Also, at the end of the day the client will have to get the reports to show the user where the validation is crashing (namely, getting the results xml)

Anyway it's feasible, so basically the logic would be:

1- if the script has a port with media-type="application/xml+vnd.pipeline.status" -> read the port  @result=(not-valid  | valid) if valid the job status is DONE, if not-valid status=FAILED:

what if the xml coming from that port is doesn't follow the format? is that an error? in fact the job is done an the results are available...

cheers,

Javi

[Jostein Austvik Jacobsen]

 IMO a failed validation doesnt seem appropriate as job status, the job itself didn't failed.

As an alternative we could create a separate attribute for the validation status; would you prefer that?

 

what if the xml coming from that port is doesn't follow the format? is that an error? in fact the job is done an the results are available...

Yes, I would say it's an error to not return a validt status document. It's up to the script author to return a valid status document.

By the way, we keep mentioning "application/xml+vnd.pipeline.status", but I think it is more correct with "application/vnd.pipeline.status+xml". Compare with for instance "application/xhtml+xml" or "application/x-dtbook+xml".

Jostein