Skip to content
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

Option default values #833

Open
ndw opened this issue Jul 10, 2019 · 9 comments

Comments

Projects
None yet
2 participants
@ndw
Copy link
Contributor

commented Jul 10, 2019

Consider this statement:

Some steps accept options. The value of an option is the default value specified in its declaration, or a value provided by the caller of the step (overriding the default). If it has neither a default value nor a provided value, its value is the empty sequence.

I don't think it's that simple. Consider an option that has a type for which the empty sequence is not a valid value.

<p:option name="prefix" as="xs:NCName"/>

If I don't specify a value for prefix and the implicit default empty sequence value is used, then the value isn't legal according to the declared type.

Is that an error?

Is it an error if I specify prefix="{()}"?

Is it an error if I make the empty sequence default explicit?

<p:option name="prefix" as="xs:NCName" select="()"/>

If it's possible to come up with a rule that gives the same answer for all of these cases, I'd vastly prefer that over some context-dependent answer.

@xml-project

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

Let us argue that these cases should be only an error if I do not supply a valid value on call. (Of course the processor is free to raise a warning if the default value wouldn't fit.)

We currently have

It is a dynamic error (err:XD0036) if the supplied value of a variable or option cannot be converted to the required type.

Do indicate the possible course of the error more precisely we could change the error text:

It is a dynamic error (err:XD0036) if the supplied or defaulted value of a variable or option cannot be converted to the required type.

Does this work?

@xml-project

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

In the same line of thought is our handling of default port connections: Suppose a default connection is defined which does not satisfy the content-type attribute for this port (e.g. JSON document on an XML port). It was argued that the error should only be raised, if the default content is actually used. Then it's XD0038.

@ndw

This comment has been minimized.

Copy link
Contributor Author

commented Jul 11, 2019

I think I can play your argument back the other way, if the user does not supply a value, then the default is used and, in the case of the content type, that would raise an error. FWIW, if you send this stylesheet to itself:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns:xs="http://www.w3.org/2001/XMLSchema"
                exclude-result-prefixes="xs"
                version="2.0">

<xsl:output method="xml" encoding="utf-8" indent="no"
            omit-xml-declaration="yes"/>

<xsl:template match="element()">
  <xsl:copy>
    <xsl:apply-templates select="@*,node()"/>
  </xsl:copy>
</xsl:template>

<xsl:template match="xsl:template">
  <xsl:param name="myparam" as="xs:NCName"/>
  <TEMPLATE/>
</xsl:template>

<xsl:template match="attribute()|text()|comment()|processing-instruction()">
  <xsl:copy/>
</xsl:template>

</xsl:stylesheet>

it raises an error:

Error on line 17 column 45 of out.xsl:
  XTDE0700: A value must be supplied for parameter $myparam because the default value is not
  a valid instance of the required type
  at xsl:apply-templates (file:/tmp/out.xsl#12)
     processing /xsl:stylesheet/xsl:template[1]
  in built-in template rule for /xsl:stylesheet in the unnamed mode
A value must be supplied for parameter $myparam because the default value is not a valid instance of the required type

I think this argues for raising an error if a non-required option has a type for which the empty sequence is not valid.

@xml-project

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

I am not sure we disagree on this. I would fully agree with:

I think this argues for raising an error if a non-required option has a type for which the empty sequence is not valid.

Actually no one can disagree to this rule, can one?

What have I missed?

@ndw

This comment has been minimized.

Copy link
Contributor Author

commented Jul 11, 2019

I don't know, perhaps I misunderstood. In an earlier comment, you said "[it] should be only an error if I do not supply a valid value on call." I interpreted that to mean that you thought it wasn't an error in the case where () is being selected as the default.

@xml-project

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

Precisely. Consider:

<p:declare type="some:thing">
   <p:option name="name" as="xs:NCName" /> <!-- no error here -->

</p:declare-step>

<some:thing /> <!-- Dynamic error here, because default () is used. -->
<some:thing name="name" /> <!-- No error here because value is correct -->

Do you argue for a static error at declaration? I took your XSLT example to argue for a dynamic error if the default is used since XSLT raises a dynamic error and no static error.

In the specs we say:

The default value of an option is specified with an XPath expression on the p:declare-step that defines the step signature. 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 dynamic error (err:XD0026) if the select expression makes reference to the context node, size, or position.

So I can do this:

<p:declare-step>
  <p:option name="opt1" required="true" />
  <p:option name="opt2" as="xs:boolean" select="$opt1" />

IMHO there is no way to statically decide whether $opt1 satisfies xs:boolean.

BTW: I think we should add static variables to the above quoted text.

Did I state my point better?

@ndw

This comment has been minimized.

Copy link
Contributor Author

commented Jul 11, 2019

Ok. We're in agreement and I just misunderstood you earlier. Apologies for that. No, I'm not proposing that it's a static error.

Yes, we should add variables to that paragraph.

@xml-project

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

OK. Sorry for causing confusion.

@xml-project

This comment has been minimized.

Copy link
Contributor

commented Jul 12, 2019

Summary of actions:

  1. Change text of XD0036 to: It is a dynamic error (err:XD0036) if the supplied or defaulted value of a variable or option cannot be converted to the required type.

  2. Add static variables to "Consequently, if it contains variable references, they can only be references to preceding options on the step."

Do I have forgotten something?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.