New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Static evaluation of attributes and descendants of p:input #542

Closed
xml-project opened this Issue Sep 16, 2018 · 8 comments

Comments

Projects
None yet
4 participants
@xml-project
Copy link
Contributor

xml-project commented Sep 16, 2018

Currently we say:

Several kinds of expressions are evaluated during static analysis: [...]
2. Value templates in the attributes or descendants of p:input [...] and map attributes on those descendants.

Do we want static errors to be raised during analysis of p:input, even if we can not determine by static analysis, if the default binding is actually used.

Options:

  1. Yes, the static analysis of attributes, AVT/TVTs and map expression raises statical errors.
  2. No, the error is statically detected, but it is raised dynamically, if the default binding is actually used.

What do you think?

@gimsieke

This comment has been minimized.

Copy link
Contributor

gimsieke commented Sep 16, 2018

Isn’t this similar to #454, and the solution is 2.?

@xml-project

This comment has been minimized.

Copy link
Contributor

xml-project commented Sep 17, 2018

To my reading #454 is about evaluation of default binding (especially accessing external resources), and there we have a solution.
My point is broader as it includes evaluation of XPath expressions in attributes:

  • p:input/@href
  • p:input/p:document/@href
  • p:input/p:document/@document-properties
  • p:input/p:document/@parameters
  • p:input/p:inline/@document-properties
  • Any AVT/TVT as descendant of p:input
  • Any AVT/TVT as descendant of p:input/p:inline

AND

  • p:output/@href
  • p:output/p:document/@href
  • p:output/p:document/@document-properties
  • p:output/p:document/@parameters
  • p:output/p:inline/@document-properties
  • Any AVT/TVT as descendant of p:output
  • Any AVT/TVT as descendant of p:output/p:inline

But one might argue, that if we answer #454 with (2), we should use this concept here too.

@eriksiegel

This comment has been minimized.

Copy link
Contributor

eriksiegel commented Sep 17, 2018

IMHO when the possibility exists that the validity of an expression can not be determined at static analysis, it should always raise a dynamic error.

Only when an expression can or should always be evaluated totally static (like a @select at a static variable) it should be done at static analysis time.

@xml-project

This comment has been minimized.

Copy link
Contributor

xml-project commented Sep 17, 2018

@eriksiegel It depends on what you call the "expression": This could either mean the XPath expressions enumerated in my last comment or the p:input/p:output as a construct.

If you take the first meaning of "whole expression", then any error is determined statically, because the expression has to be evaluated statically. In the second sense of "whole expression" it is not clear, because from a static analysis I can not know, whether the defective XPath expression is relevant.

@xml-project

This comment has been minimized.

Copy link
Contributor

xml-project commented Sep 17, 2018

An additional problem may come up, if we go for the "dynamic solution" (2).
As the static analysis may discover more than one error to be raised dynamically if the default binding is actually used: Which one is to be raised, so it could be caught?
Currently we do not have a concept of order (or accumulating) dynamic errors, so different processors could take different errors to be raised. This makes the outcome of a defective pipeline running on different processors unpredictable. (Please mind the difference between static errors, which cause the pipeline to fail, and dynamic errors, which may invoke another part of the pipeline to be executed!)
If we go for the dynamic solution (as @gimsieke proposed), we should have an answer to "which error to raise". May be this could be a theme for Thursday's telcon?

@ndw

This comment has been minimized.

Copy link
Contributor

ndw commented Sep 20, 2018

At the 20 Sep editor's call, we agreed that a step that has an input port that's unbound, if there is no
default readable port, will use the declared default for that port. (So you can reuse the default in several invocations.)

@xml-project

This comment has been minimized.

Copy link
Contributor

xml-project commented Sep 20, 2018

We also agreed 20 Sep editor's call that all errors detected during statical analysis of attributes and descendants of p:input are raised statically (possibly using XD-error codes).
Right?

@ndw

This comment has been minimized.

Copy link
Contributor

ndw commented Jan 6, 2019

Yes. Let's make this as simple as we can.

I can't, at the moment, think of an example of an error that we could report statically that might not happen for a different input.

@ndw ndw self-assigned this Jan 8, 2019

@ndw ndw closed this in #698 Jan 8, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment