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

Default value for (non-static) options #506

Closed
xml-project opened this Issue Aug 14, 2018 · 7 comments

Comments

Projects
None yet
3 participants
@xml-project
Contributor

xml-project commented Aug 14, 2018

Currently we say on the default value for (non-static) option:

It must be a statically valid expression at that point. Consequently, if it contains variable references, they can only be references to preceding options on the step.It is a static error (err:XS0071) if the XPath expression refers to the name of a variable that is not present in the in-scope bindings. It is a dynamic error (err:XD0026) if the select expression makes reference to the context node, size, or position.

  1. I would expect static options/variables lexically preceding the step signature to be visible too.
  2. Since the XPath expression in @select has to be examined during static analysis to raise XS0071, I would suggest that making reference to a context node etc. is a static error too.
@ndw

This comment has been minimized.

Contributor

ndw commented Aug 14, 2018

“Maybe.”

Consider

<p:declare-step …>

  <p:variable static="true" name="x" select="1"/>

  <p:declare-step type="ex:foo">
    <p:option name="a" select="$x"/>
    <p:option name="b" select="$x"/>
    …
  </p:declare-step>

  <p:variable name="x" select="2"/>

  <ex:foo>
    <p:with-option name="b" select="$x"/>
    <!-- ??? -->
  </ex:foo>

  …
</p:declare-step>

At the point marked ???, what are the values of $a and $b and why?

@xml-project

This comment has been minimized.

Contributor

xml-project commented Aug 14, 2018

Answer:
a=1, b=2

Proof (Assuming for first p:variable has a missing (@static='true'):

  1. "The values of static options and variables are computed during static analysis." see here
  2. We could therefor imagine every occurrence of $x to be replaced by the value computed for $x.
  3. The declaration ex:foo would then be equivalent with:
<p:declare-step type="ex:foo">
    <p:option name="a" select="1"/>
    <p:option name="b" select="1"/>
    …
</p:declare-step>
  1. It does not matter whether the second variable has a missing `@static=true' (At that position it might be static or dynamic).
  2. Since no value is provided for option a on the call of ex:foo, the default value is used. This is "1", so a=1.
  3. A value for b is provided, and the provided value is "2", so b=2.

Q.E.D.?

@ndw

This comment has been minimized.

Contributor

ndw commented Aug 14, 2018

Okay. I agree that's the answer. From an implementation perspective, it's quite interesting. It means that the binding for $x for one expression is different than the binding for $x for the other expression.

I implemented bindings like pipes between steps so there's no obvious way to (a) have two different bindings for $x or (b) distinguish between them. But I'm game if you are, I guess.

@xml-project

This comment has been minimized.

Contributor

xml-project commented Aug 14, 2018

I implemented bindings like pipes between steps so there's no obvious way to (a) have two different bindings for $x or distinguish between them.

Similar here: The XDM-value is produced and then send to the implementation of the step on which the $x occurred.
But with the arrival of static variables/option and the requirement, that the values (and errors) have to be evaluated statically, I do not handle them as messages between actors. I use a classical value map for static variables/option. This was why I said, that my implementation broke because of static options/variables.

What about the second point in my initial posting: Raising a static error?

A third point occurred to me in the meantime: What if the p:option has an @as and the computed value for @select does not conform to the given SequenceType. I would opt for this to be a dynamic error raised iff the default value is known to be used. Sounds reasonable?

@ndw

This comment has been minimized.

Contributor

ndw commented Aug 18, 2018

I'd over looked the fact that that first variable has to be static. Yes, that helps.

If we're going to evaluate the defaults statically, then yes, raising the error statically makes sense.

I can go either way on the third point above. I don't see any particular advantage to the user to allow them to specify a bogus default value that only sometimes raises an error. But I don't object to delaying the check to runtime.

@gimsieke

This comment has been minimized.

Contributor

gimsieke commented Sep 5, 2018

Resolution: Static variables may not be shadowed by dynamic variables (by any variables).

@ndw ndw self-assigned this Nov 1, 2018

@ndw

This comment has been minimized.

Contributor

ndw commented Nov 6, 2018

Should have been marked fixed by #615

@ndw ndw closed this Nov 6, 2018

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