This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 21005 - [XPROC10] Specification errors with regard to in-scope bindings.
Summary: [XPROC10] Specification errors with regard to in-scope bindings.
Status: ASSIGNED
Alias: None
Product: XML Processing Model
Classification: Unclassified
Component: Pipeline language (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Norman Walsh
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-15 08:42 UTC by Tim Mills
Modified: 2014-03-19 14:23 UTC (History)
0 users

See Also:


Attachments

Description Tim Mills 2013-02-15 08:42:55 UTC
In Section 2.5 Environment it is stated

"The in-scope bindings have to be calculated as the pipeline is being 
evaluated."

Since the in-scope bindings are required in static analysis (e.g. It is 
a static error (err:XS0020) if the binding attribute on p:namespaces is 
specified and its value is not the name of an in-scope binding) this 
should be split into two properties.  The first is the set of statically 
known in-scope variable and option names, the second is the set of 
dynamically known variable and option values.

Section 2.5 goes on to explain how the in-scope bindings are updated 
from p:variable elements.  I can find no text in the specification which 
states how options are added to the in-scope bindings.
Comment 1 Norman Walsh 2014-02-19 11:48:49 UTC
We accept your observation that it should be broken into static and dynamic phases but are inclined to postpone that to 2.0.

We do agree that the binding of options is only referred to indirectly. We propose to add a new bullet to the first list in 5.8.2:

  The names and values of all options that have values (provided by
  the caller or computed from defaults) are added to the in-scope
  bindings.

This does nothing to resolve the static/dynamic issue, but we hope clarifies that they do get added!

As a result of reviewing the spec, we believe that the paragraph beginning "All in-scope bindings for the step instance..." has been mistakenly copied into 5.7.3 and 5.7.4 and should be removed.
Comment 2 Tim Mills 2014-02-19 13:15:28 UTC
It's a while since I looked at this, but I'm slightly concerned about
"that have values " in your suggested text:

"The names and values of all options that have values (provided by
 the caller or computed from defaults) are added to the in-scope
 bindings."

The environment only has "in-scope bindings", which corresponds to the XPath dynamic context's "variable values".  So what you've suggested is absolutely correct.  However, the environment doesn't have an equivalent of the static context's "in-scope variables".  This means it's not entirely clear whether it's possible to compile an XPath statically, because the XPath might refer to an option name that isn't actually in-scope.  That's a static error, as opposed to the dynamic error encountered when an in-scope variable doesn't have a value.

I expect to be able to compile an XPath expression within XProc statically, knowing that an option is in-scope, regardless of whether at run time that option will have been supplied with a value.

Making this clear in the spec might involve explicitly splitting the environment into static and dynamic components.  i.e. not likely as an erratum!
Comment 3 Norman Walsh 2014-03-19 14:23:43 UTC
Thanks, Tim. We agree that splitting the environment into static and dynamic parts is the right answer and more than we want to do in an erratum! We propose to add the following note somewhere in 5.8.2 as well:

  The fact that XProc 1.0 conflates the notion of variable binding
  across the static and dynamic contexts means that attempting
  to compile XPath expressions in a purely static way will still
  require determining whether or not there are bindings for all
  the XPath variable in the expression at runtime.

that at least confesses our error.