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

[Bug 29832] [FO31] fn:transform options

From: <bugzilla@jessica.w3.org>
Date: Wed, 21 Sep 2016 00:35:30 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29832-523-iQk9qJMc6g@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29832

--- Comment #2 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
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".

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 21 September 2016 00:35:40 UTC

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