Leigh Klotz, Xerox (chair, minutes)
Erik Bruchez, Orbeon/Inventive Designers
Nick van den Bleeken, Inventive Designers
Alain Couthuries, AgenceXML
Philip Fennell, Mark Logic
Kurt Cagle, XMLToday
August 29-31, 2011, in SF Bay Area.
Philip Fennell: Based on the
previous discussion where I put forth the idea that a
transformation was very similar to a submission in the things you
might need to define, I took as a template the description for the
submission module and came up with something that attempted to do
the same sort of things for the transformation. You need to define
the URI of the transformation and the instance you want to
transform and where you want the transform results to go, plus some
additional attributse such as additional mode and template name
(for XSLT 2).
Philip Fennell: Does this cover a
valuable set of scenarios for transformations in XForms? If it
does, then once we have a way of defining a transformation, how do
we go about invoking that transform? There was some discussion
about function vs action. I don't really mind either way, though I
was originally in favor of action. The function examples are very
nice and stylish and I find them quite compelling in their own
way.
Leigh Klotz: Is there a reason we have
to choose?
Philip Fennell: We should do one
before the other. I had problems with setting up the transformation
through the function and I thought you needed the flexibility of an
action. If the transformation is described separately, then it can
still be be concise in the invocation and we don't need the
action.
Nick van: You don't need the target in
the function; the function returns the result of the
transformation.
Philip Fennell: If you define a target
in the definition, that would be overridden in the function.
Leigh Klotz: We shouldn't have XPath
functions with side effects so it would be overridden 100% of the
time.
Philip Fennell: That's true.
Nick van: If we have an action then
the target could be on the action. There are use cases where you
want the same transformation targeted in two places. So we'd want
to override the ref or bind for the input as well. On the other
hand, a couple of years ago we were talking about making the XForms
syntax more lightweight and overriding the submission attributes in
the action. Maybe this is something we could do there; you could
define it in the model and override in the action or function. It's
harder in the function; how would the implementation know when to
recompute the dependencies?
Nick van: Another thing on the
transformation element: we need parameters. Most transformation
languages have external parameters.
Leigh Klotz: I thought this proposal
had that.
Philip Fennell: It's there -- the
param element.
Nick van: I missed it. I was only
looking at the top of the page.
Leigh Klotz: Are the params nodesets
or strings?
Nick van: In XSLT you can have a
nodeset.
Philip Fennell: In XSLT 2, with
types.
Nick van: I'm not sure if it's
supported. ...
Kurt Cagle: [joins]
Kurt Cagle: I'd push for nodesets, or
sequences, for XSLT 2.
Leigh Klotz: It's for a generic
transform, even XProc.
Kurt Cagle: I see.
Leigh Klotz: I'd say how about
nodesets and let the transform module documentation say what it
wants to do about converting, first-node rule or whatever.
Nick van: Yes, it should say how to
convert to string if it needs a strong.
Philip Fennell: I will update the
page.
Philip Fennell: Another thing about
defining the transform: does that have to be an external file
reference or could it be something retrieved from another instance
in the form.
Leigh Klotz: I thought you meant #foo
but I see you mean in the instance as we well.
Philip Fennell: I got the impression
that we were at cross purposes. When I referred to using fragment
identifiers, I was imagining resolving them within the XForm rather
than the host document. #foo would resolve to an instance, not the
HTML page. That might lead to some ambiguity.
Leigh Klotz: Others have used # to
refer to schemas in the host document.
Nick van: We've had URI with #
pointing to the normalized document, not the live instance.
Leigh Klotz: Philip is talking about a
URI scheme that would point to instance data.
Philip Fennell: Is there a way to use
the fragment identifier to refer to an instance in the model? Then
we wouldn't have to concoct some way of addressing stylesheets with
more than one attribute.
Nick van: We typically plug in a
custom URI scheme. For example, we define "xforms:" so that
"xforms://instanceid" to get live instance data. That might be hard
for some implementations to support a custom schemes.
Leigh Klotz: Where do you use that URI
now?
Nick van: Not in XForms, but in other
applications that access custom XSLT data or other areas with our
own custom resolver.
Philip Fennell: Apache Coccoon has
coccoon: and resource: that resolve in their own ways. That's where
I got the idea from.
Nick van: It's used in other areas,
too. To communicate back from HTML application to native
side.
Kurt Cagle: The string that references
XSLT is XPath to a model (live), an internal pointer (# to a
resource in the page), or an external resource URL.
Nick van: Wouldn't the other way be
more logical: if it's a #id then it's internal so "xforms:xyz//"
gives you an XPath to an instance.
Kurt Cagle: I'd go with the other
route as it's more familiar. Look at what the scheme SVG uses, for
internal references to entities.
Leigh Klotz: What scheme?
Kurt Cagle: It uses a url
function.
Leigh Klotz: We already have
instance/@src so we don't need a new XPath function to retrieve an
unnamed instance.
Kurt Cagle: I see no problem.
Leigh Klotz: Then it would always be
in an instance.
Nick van: If you care to know when
it's changed.
Leigh Klotz: Then maybe we need two
attributes, src or resource and ref.
Philip Fennell: ref is used for the
input of the transform.
Nick van: That should be in the
function argument instead as that makes the dependency engine work
better. It's more powerful to provide as a parameter of the
function as you can do logic in the context of where you are
executing the transformation, for example a local node that changes
if you are in a repeat.
Kurt Cagle: So are we assuming the
transform can be modified via XForms system?
Nick van: If it is in an instance. I'm
not a big fan of that. But there are some people who want
that.
Leigh Klotz: We might not get
everybody to implement @ref because of the difficulty, but
everybody should be able to do @src or @resource with external URI
or #id uri, and some implementations can use. And we'll leave @ref
unused in case we want to have it live transform instances in the
future.
Erik Bruchez: OK. I'd recommend a
resource child element as well.
Philip Fennell: It's in the
spec.
Nick van: If you put resource child
element in the transformation, the context is where the
transformation element is defined, not where it is invoked. So in a
repeat, it's the same resource.
Leigh Klotz: Do we have a way to pass
in parameters that depend on the evaluation context?
Nick van: I think the parameters are
defined at the element. The actual values are in the
function.
Leigh Klotz: You could then define an
XSLT transform that does whatever you want based on the parameters.
I think we should avoid putting in logic to decide what transform
to use, when the transform will already have logic.
Nick van: I see.
Kurt Cagle: I would be loathe to keep
the transform as a static. I think there are enough use
cases.
Leigh Klotz: Nick's point is the
invocation of the function isn't where the context for the resource
evaluation comes from.
Kurt Cagle: The function itself isn't
an issue. There was a mission of attributes. If you have a resource
attribute on the action or transform element, that should be
dynamic.
Leigh Klotz: It's the static
evaluation context of the model. And as Erik would say if we had
AVT we wouldn't need the resource child.
Erik Bruchez: Yes.
Kurt Cagle: Sounds good.
Philip Fennell: I'm making notes and
will update the wiki.
ACTION-1815 Philip Fennell to update The XForms Transform Module with results of discussion about transform @resource and resource URI.
Philip Fennell: Another issue is
xsl:message/@terminate="yes" generating an xforms-transform-error
ecvent.
Nick van: What is the target of the
event? We say you can't have two of the same submission running at
the same time. But we don't have that.
Leigh Klotz: Maybe it should be a
compute exception from the function.
Philip Fennell: The example I put in
showed put up a message.
Leigh Klotz: I have a proposal for
using uniqifiers for submissions in progress.
Nick van: The error should be dispatch
to where you invoked the transformation.
Leigh Klotz: If you have it in a
bind/@calculate, where does the error happen?
Nick van: In the bind. But if it's in
the UI you would have it there.
Kurt Cagle: That gets into fairly
significant debugging.
Leigh Klotz: You mean
output/@value.
Nick van: If you had an error you
could say "your name couldn't be retrieved" and it could display
there.
Kurt Cagle: I'd be wary; that
information depends on the transformation engine.
Nick van: If the transformation fails
or the URI can't be resolved, somewhere an error should
happen.
Kurt Cagle: Is there any benefit for a
transformation-load an transformation-load-error or are those just
resource-load and resource-load-error. An error in the XSLT would
reflect the engine's error messages and would dependent on the
engine. A timeout or URL resolution would be load error.
Leigh Klotz: Philip brought this up
with xsl:message/@terminate="yes" where the author is trying to
communicate to us.
Nick van: I think they are adding
try/catch fallback so if the function throws the error then you can
do something.
Leigh Klotz: That's why I said a
compute exception but you can't tell from another exception.
Nick van: There could be context
information.
Philip Fennell: I have no-data,
validation-error, parse-error, and resource-error. Sounds like we
need to add transformation-error which could include
message/@terminate="yes".
Leigh Klotz: Or termination error. If
it's possible to tell the transformation was terminated by
request.
Philip Fennell: You can distinguish in
the XSLT engines I've used.
Leigh Klotz: If the engine doesn't
offer a way for the author to do that then you'll never get
one.
Nick van: If we send the error where
you define the transformation it's ok because there's no
information from the invocation, but you can now pass
parameters.
Leigh Klotz: How about we define the
default handler on the the transform element catches the exception
and turns into a compute exception on the function, but if you
catch it and cancel it then it doesn't.
Nick van: There might be trouble
running event handlers inside the XPath computation.
Leigh Klotz: We should ask John Boyer.
He will have an opinion on this.
Kurt Cagle: How about
transform-load event? Some are big. You're bypassing the
instance-load infrastructure.
Philip Fennell: instance/@src doesn't
give you events either. You don't get the ability to trap events on
loading of resources. You trap it only if you get it indirectly
through an instance.
Leigh Klotz: You're modelling
transform on submission so you might as well put the event in. I
think it's likely that the indirect instance transform source won't
make it in to implementations because of the dynamism.
Philip Fennell: I see.
Leigh Klotz: You might want to write
that up for the meeting and we'll discuss it there.