W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2016

[Bug 29832] New: [FO31] fn:transform options

From: <bugzilla@jessica.w3.org>
Date: Tue, 20 Sep 2016 13:17:40 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29832-523@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29832

            Bug ID: 29832
           Summary: [FO31] fn:transform options
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Functions and Operators 3.1
          Assignee: mike@saxonica.com
          Reporter: abel.braaksma@xs4all.nl
        QA Contact: public-qt-comments@w3.org
  Target Milestone: ---

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 20 September 2016 13:18:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:58:02 UTC