Re: Composability

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| OK, so you think that's easy because you can detect that the option
| has been set from a node in a document so you just pick up the
| in-scope namespaces from that node. Now try this one:
|
|   <p:matching-documents>
|     <p:option name="test"
|       select="concat('/xhtml:html/xhtml:head/rdf:RDF[',
|                      /my:config/my:filter/@test, ']')">
|       <p:pipe step="top" source="config" />
|     </p:option>
|   </p:matching-documents>
|
| The namespace set needs to contain the in-scope namespaces from the
| config document *and* some namespaces from the pipeline environment
| (if those namespaces are even declared).

I'm sorry, why isn't it the responsibility of the pipeline author
to provide in-scope bindings for xhtml: and my: on this option?

   <p:matching-documents xmlns:xhtml="...">
     <p:option name="test" xmlns:my="..."
       select="concat('/xhtml:html/xhtml:head/rdf:RDF[',
                      /my:config/my:filter/@test, ']')">
       <p:pipe step="top" source="config" />
     </p:option>
   </p:matching-documents>

That's what my implementation would expect.

I grant that I don't have a solution for this situation:

  <p:option name="someexpr" select="/config/@find">
    <p:document href="/path/to/config.xml"/>
  </p:option>

  <p:matching-documents>
    <p:option name="test" select="$someexpr"/>
  </p:matching-documents>

where the bindings in config.xml are unconstrained.

But I'm also not sure that the world will end if we don't solve that
one in V1.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | When the situation is desperate, it is
http://nwalsh.com/            | too late to be serious. Be
                              | playful.--Edward Abbey