This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29832 - [FO31] fn:transform options
Summary: [FO31] fn:transform options
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.1 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2016-09-20 13:17 UTC by Abel Braaksma
Modified: 2016-12-16 19:55 UTC (History)
1 user (show)

See Also:


Description Abel Braaksma 2016-09-20 13:17:40 UTC
I am missing some options that influence stylesheet behavior and are available in XSLT 3.0:

- switch assertions on or off, suggestion name "assertions", value xs:boolean
- turn dynamic evaluation on/off
- set required XPath version
- request XSD 1.1 support
- backwards/forwards compatibility mode (see earlier bug 29830)
- switch fn:trace or xsl:message reporting on/off
- processor name + version (similar to system-properties, I suggest to mimic the same names as defined for fn:system-property), this can be of influence, for instance by calling a validating processor and wanting it to fail when such processor is not available
- similar to previous point: ability to switch validation on/of
- set environment variables for the execution context of the processor (though one can argue that this is too processor-dependent anyway, having the same name between processors is beneficial)
- switch streaming on/off. This has no influence on processing the stylesheet, but can be used to *require* a streaming processor

For some of these options you may argue that they are too processor-specific. But I think we should allow a user to make sure his expectations are met. If his stylesheet expects "3 > foo/@test" to never fail, he must able to require such behavior.

Of more importance are dynamic evaluation (security!), assertions (also security, and usability), processor name/version.

Most of these items have a counterpart in fn:system-property, we could simply take that name for a value in the options map.
Comment 1 Michael Kay 2016-09-20 19:19:32 UTC
I like the suggestion that many of these are inverses of the system-property() interrogative, and suggest we add a new option:

required-properties - a map describing the required properties of the XSLT processor to be used. If an entry with key K and value V is present in this map, this indicates a requirement that the processor should be one for which system-property(K) returns the value V, or a value considered by the implementation to be equivalent in the sense that applications are unlikely to be affected by the difference (for example a request for xsl:product-version="9" might return a processor with xsl:product-version=""). However, any setting of xsl:version in this map is ignored since it would duplicate the effect of the xslt-version option. A value of "no" for a feature such as "is-schema-aware" or "supports-dynamic-evaluation" explicitly requests a processor that does not support this feature; if the application doesn't care whether the feature is supported or not, then no value should be supplied for this property in the required-properties map.

This covers most of your suggestions. For the remainder, I suggest top-level options:

enable-assertions  boolean  default false, switches assertion checking on or off
enable-trace       boolean  switches fn:trace on or off; default is impl-def
enable-messages    boolean  switches xsl:message on or off; default is impl-def

I think that validation is a bit of a minefield and we should leave it out (because of the problems of saying which documents we're talking about validating, and the interaction with other facilities such as xsl:source-document/@validation, and input-type-annotations).

I don't see a need to set environment variables - static parameters are much more useful.
Comment 2 Abel Braaksma 2016-09-21 00:35:30 UTC
Re comment#1:

> I think that validation is a bit of a minefield and we should leave it out
Isn't that essentially covered by "required-properties" using "xsl:is-schema-aware"? Setting that to "false" for a schema-aware processor can invoke that processor with schema-validation and type checking turned off.

That's similar in how I envision xsl:supports-streaming is going to work. One processor may support streaming and non-streaming, and this can then be invoked by setting this property to true or false respectively.

> I don't see a need to set environment variables - static parameters are much 
> more useful.
Makes sense. Let's leave it to that.

This (your proposal) effectively creates the ability for users to test their stylesheets against a variety of configurations, which in turn may open the door for some serious XSLT Unit testing frameworks to emerge (here's hoping ;).

But I digress, I like the proposal.

One note: apart from xsl:version, which has no place here, I think xsl:vendor-url and xsl:vendor, have no lookup semantics. But we can also leave that to be defined by the implementers (which is the status-quo).

I think that the boolean values should be treated as xs:boolean, not as string "yes" or "no", or "true" or "false".
Comment 3 Michael Kay 2016-09-22 14:49:16 UTC
One other observation which I'll add given that we are reviewing this: the spec talks of the options map containing a specified list of options "and nothing else", which is inconsistent with the optional parameter conventions, which indicate that superfluous options are ignored.
Comment 4 Michael Kay 2016-09-27 20:37:10 UTC
The proposed change has been implemented; the bug is left open so the WG can review the editor's proposed text.
Comment 5 Abel Braaksma 2016-09-29 13:53:02 UTC
Thanks. I have read it in the current internal WD and it looks good to me. Esp. the part that explains that a processor can ignore parts of this as it sees fit, or raise FOXT0001.
Comment 6 Andrew Coleman 2016-10-07 10:51:15 UTC
At the meeting on 2016-10-04, the WG reviewed and approved the change.