Re: Low hanging fruit for V.next [revised]

James Fuller <jim@webcomposite.com> writes:
> could we consider one simplification related to parameters … e.g.  if
> we allow data model frags in options and variables couldn't we allow
> an option or variable to contain a
>
> <c:param-set>
>     c:param*
> </c:param-set>
>
> or
>
> <c:param/>
>
> which means we could remove the notion of an parameter port (replace
> with p:with-param) and simplify the language whilst retaining
> everything we can do now.

Here's the hard case that has to be handled: I have to be able to
run this pipeline:

<p:pipeline>
  <p:xslt>
    <p:input port="stylesheet">
      <p:document href="docbook.xsl"/>
    </p:input>
  </p:xslt>
</p:pipeline>

pass parameters to the pipeline and have those parameters available
inside the stylesheet without enumerating all of them in the pipeline.

How do I easily create a c:param-set for a hypothetical 'parameters'
option without invoking even more magic than we currently have?

>> Can you think of any others?
>
> * we touched upon it e.g. p:document and p:data could be merged

Yes.

> * thinking out loud, wonder if there is a way to merge the context
> defined by elements p:xpath-context, p:viewport-source,
> p:iteration-source

Perhaps. It occurs to me that if we adopt XPath 2, AVTs, and allow
variables to contain sequences of documents then we could use an
option to point to the context.

  <p:for-each iteration-source="{$documents}">...

> * assist making it easier to create cross platform pipelines e.g.
> file.separator in file paths

Where do file.separators come into play? We're using URIs pretty much
everywhere except p:exec which does support platform-specific
separators.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 413 624 6676
www.marklogic.com