This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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="9.0.0.1"). 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.
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".
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.
The proposed change has been implemented; the bug is left open so the WG can review the editor's proposed text.
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.
At the meeting on 2016-10-04, the WG reviewed and approved the change.