Re: In-scope namespaces and parameter values

On 3/12/07, Jeni Tennison <jeni@jenitennison.com> wrote:
>
>
>
> > Our component terminology might be a little bit confusing in
> > that there typically is a "configuration wrapper" layer that
> > takes the information provided by the XProc processor and
> > configures an actual implementation technology.  In the
> > case of XSLT 2.0, it would be instantiating and configuring
> > the XSLT engine and transformation.
>
> Yes: that was the distinction I was making between the "component" (the
> wrapper) and the "processor" (the actual implementation of the
> technology).
>
> Do I take it you agree with me that we can get away with just having a
> warning in the spec about the fact that different namespace associations
> might be in scope when an option value is specified (e.g. in the
> invocation of a pipeline) to when the option value is provided to the
> component (at the invocation of a step). Or do you have an alternative
> solution to that problem?


More like a note... that is already true for languages like XSLT and
their contained XPaths.  I think we need to state that the processor
provides the in-scope namespaces on the element where the option
value is specified.  The fact that they can be different is a subtle point
that should be noted but it isn't like we've done anything "wrong".  If a
user is confused by that, the simple solution is "don't do that!".  That is,
define a constant set of prefixed for your namespaces and use the
appropriately.

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics