The default values for options and ports are not exposed through the Web API

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start Pipeline 2 in local mode
2. GET http://localhost:8181/ws/scripts/daisy202-to-epub3
3. Inspect the "mediaoverlay" and "compatibility-mode" options

What is the expected output? What do you see instead?
The "mediaoverlay" and "compatibility-mode" options returned are:
<option desc="Whether or not to include media overlays and associated audio 
files (true or false)." mediaType="" name="mediaoverlay" ordered="true" 
required="false" sequence="false" type="boolean"/>
<option desc="Whether or not to include NCX-file, OPF guide element and ASCII 
filenames (true or false)." mediaType="" name="compatibility-mode" 
ordered="true" required="false" sequence="false" type="boolean"/>

They correctly have the @required="false" attribute set, indicating that the WS 
knows that a default value is present. However, the default values are not 
exposed.

It was agreed upon when talking about the 
[http://code.google.com/p/daisy-pipeline/wiki/F2F201204_Oslo#Script_Metadata_Cle
anup Script Metadata Cleanup] that the default values should be exposed, but I 
don't think we described concretely how. Maybe simply @default="defaultvalue"?

Original issue reported on code.google.com by josteinaj@gmail.com on 10 Jul 2012 at 4:01

[GoogleCodeExporter]

The WS doesn't have access to the default values; it would have to first become 
available via the framework. 

Once that data is available, I'll add @default to the options/ports like you 
described.

Original comment by marisa.d...@gmail.com on 11 Jul 2012 at 6:40

[GoogleCodeExporter]

I'm not sure it's possible to make this data available unless the script 
declares it up front.

For example, dtbook-to-zedai has this option in its main XPL file:

<p:option name="zedai-filename" required="false" px:type="string">
(from 
http://code.google.com/p/daisy-pipeline/source/browse/dtbook-to-zedai/src/main/r
esources/xml/dtbook-to-zedai.xpl?repo=modules#32)

And the default value is calculated in another XPL file:
http://code.google.com/p/daisy-pipeline/source/browse/dtbook-to-zedai/src/main/r
esources/xml/dtbook-to-zedai.convert.xpl?repo=modules#120

I don't think the framework can reasonably resolve all this. If we need to know 
default values, we should declare them on the options themselves. It would be a 
little redundant but as far as I see, the only way:

<p:option name="zedai-filename" required="false" px:type="string" 
px:default="zedai.xml">

Original comment by marisa.d...@gmail.com on 11 Jul 2012 at 7:49

[GoogleCodeExporter]

The idea was to use p:option/@select to declare the default:
http://www.w3.org/TR/xproc/#p.option

That said, this is only feasible when the expression in @select can be 
statically evaluated (e.g. a string literal). As you say the fwk cannot 
reasonably resolve the default when:

 1. the @select depends on the dynamic context (e.g. values of previous options)
 2. the option is not discarded in favor of a hard-coded value (as in the example of comment #2)

Original comment by rdeltour@gmail.com on 11 Jul 2012 at 8:39

[GoogleCodeExporter]

the previous comment should read "2. the option is discarded in favor of...".

(no way to edit a comment, really ?)

Original comment by rdeltour@gmail.com on 11 Jul 2012 at 8:40

[GoogleCodeExporter]

@select attributes that start with ' and end with ' will always be a string 
literal, right? Hmm.. at least for XProc 1.0. I think 
@select="'value1','value2'" might become valid in XProc 2.0. So @select 
attributes that start with ', end with ' and don't contain any more 's would 
always be a string literal I think...

@select attributes that cannot be parsed as a string literal, as well as ports, 
won't have a default value (but they might still have @required="true").

Yes, the default values might have to be defined in multiple redundant places 
(i.e. both dtbook-to-zedai.xpl and dtbook-to-zedai.convert.xpl), but I suppose 
we could live with that?

Original comment by josteinaj@gmail.com on 12 Jul 2012 at 8:28

[GoogleCodeExporter]

Yes, @select defining string literals are not an issue. There are possibly 
other valid defaults, like those calling a function (e.g. returning the current 
time). We can always try to evaluate the XPath with Saxon and if it raises an 
issue (e.g. unknown variable) then discard the default value.

The issue is what to do for "optional" options for which we cannot parse a 
default ? I think we can't do much, we'll simply not expose any default to the 
end user. I think it can be the script author's responsibility to provide an 
extractible default in an @select.

Original comment by rdeltour@gmail.com on 12 Jul 2012 at 9:01

[GoogleCodeExporter]

Sounds good to me.

Original comment by josteinaj@gmail.com on 12 Jul 2012 at 11:16

[GoogleCodeExporter]

Issue 252 has been merged into this issue.

Original comment by josteinaj@gmail.com on 3 Dec 2012 at 2:51

[GoogleCodeExporter]

Since the pipeline is now working for me consistently, I'll target this for 
after our next release.

Original comment by marisa.d...@gmail.com on 11 Dec 2012 at 2:03