[Bug 29146] [FO31] fn:transform options update

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29146

--- Comment #5 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
I really like the new write-up of this, it's way clearer than it used to be. I
have, however, a few remarks / questions / suggestions (and I agree to
Debbie's) (apologies, while typing, the list grew and grew...):

1) What happens when "serialization" is chosen for the result and the
serialized tree cannot be represented by the calling execution environment, for
instance because XML 1.1 is serialized, JSON is chosen in xsl:output and
contains values not representable directly as an xs:string, or an
implementation-defined type is serialized (jpg, other).

2) Should we allow users to specify additional stylesheets, i.e. for the ones
referenced in by xsl:import? If the stylesheet as a whole is generated
dynamically, the base-stylesheet-uri option will not be sufficient.

3) Can we predefine names for other options of the dynamic and static context,
i.e. timezone, date, collation, collection? Currently these would go into
vendor-options, but standardizing these as key names for the map will make
implementation-independent calls easier, even if such parts of the context are
not supported (which could be an error, a default, or ignored).

4) It would be nice if there's some way to distinguish the phase of the
returned result in error scenarios. I.e., a dynamic error in a use-when
expression (static compilation phase) should be distinguishable from a dynamic
error during evaluation or priming. But I'm not sure how this could be made
workable.

5) I'm slightly ambivalent about "stylesheet-location", since it is technically
not a location.

6) Under 2.d, "initial-mode" is repeated (it is already under 2.c)

7) the entry for "source-node" is under-defined. For XSLT 1.0 it must be a
document node, for XSLT 2.0, it can be any node. The second part of this
sentence refers only to XSLT 3.0, but this is not specified.

7a) the type for "source-node" can be "node()?", XSLT 2.0 (not sure about 1.0)
allows it to be empty.

8) typo "Theese" --> "These" (under serialization-params).

9) Serialization params requires a QName as key, should we specify that the
xsl:output params exist in no namespace?

10) If "saved" is the delivery format, is it an error if the document cannot be
saved?

11) On the same token, the transformation may succeed, but errors may be raised
after the transformation (i.e., saving the result). In such cases it may be
beneficial to have a result set *and* the reported errors (as opposed to just
blowing up).

12) XSLT 3.0 defaults to "xsl:initial-template" if not initial match selection
or template is provided (i.e., with call-template invocation). I think this
should be reflected by the options by allowing this as default if
"initial-template" is not provided and no "source-node" or
"initial-match-selection" is given.

13) Is "function-params" required? With an initial function that takes no
params, this could be optional, right?

14) XSLT 3.0 with packages, it looks as if "package-version" is only allowed
with "package-name". Is that intentional?

15) XSLT 3.0: delivery format should probably not default to "document", since
"raw" can be selected in xsl:output and otherwise that default won't work.

16) XSLT 3.0: "static-params" is not mentioned as allowed optional entry

17) Determinism: I think fn:transform will by definition be non-deterministic
with XSLT 3.0 and streaming. Though this is not possible with nodes in maps, it
can be achieved with xsl:stream.

18) Talking of streaming, perhaps we should mention this in the notes starting
with "Where nodes are passed to or from the transformation"

19) Currently, only an available node can be passed to the fn:transform
function, I assume this is deliberate? If not, can we add "source-location" to
the mix?

20) A further improvement in the text structure could be to write it up such:

1. For invocation of an XSLT 1.0 processor, the supplied options must include
all of the following and nothing else:
  a. A version of 1.0, by setting xslt-version to 1.0
  b. A source item, by setting source-node to a document node
  c. A stylesheet, by setting one of the following: [...]
  d. Other options, by providing zero or more of the following [...]

The idea being: naming each of a, b, c, d makes it a bit clearer, at least to
me, what *must* be provided and what these things are.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 3 December 2015 15:16:32 UTC