Re: Namespace bindings

On 8/15/07, Jeni Tennison <jeni@jenitennison.com> wrote:
>
> In other words, you have to look at the syntax of the select attribute
> and see if it's a single variable reference, in which case the namespace
> bindings are set to the namespace bindings of the referenced option.
> Which is what I said originally. That wasn't in your proposal, which is
> why I was confused. Looks like we're in agreement.

Right... it wasn't because I hadn't thought through the problem you elaborated
upon.   So, thanks!

I believe we are in agreement.

> > A reference to $delete refers directly to an option value and so you
> > can propagate forward the in-scope namespaces.
> >
> > An expression like:
> >
> >    concat('foo:',$delete)
> >
> > converts the option value to a string and so the in-scope namespaces are lost.
>
> OK. If we don't offer any help with values created by concatenation, I'd
> like to have a component like:
>
> <p:declare-step type="p:to-xml">
>    <p:option name="value" required="yes" />
>    <p:output name="result" />
> </p:declare-step>
>
> that takes a 'value' option and creates a <c:result> element whose value
> is the value of the 'value' option *and* that has namespace bindings
> that reflect the namespace bindings on the option.
>
> That will at least provide *a* (fairly convaluted) means of constructing
> namespace bindings for options when their values are created through
> concatenation.

I think that'd be a good addition.  I'm all for it.

-- 
--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

Received on Wednesday, 15 August 2007 21:34:05 UTC