Extending p:log (action A-214-01)

Good morning,

Here's a sketch for extending p:log. Change the content model as follows:

   <p:log
     port = NCName
     href? = anyURI>
     (p:assert | p:message)*
   </p:log>

Where p:message is:

  <p:message> text </p:message>

and p:assert is:

  <p:assert
    test = XPathExpression > text </p:assert>

Extend the semantics of p:log as follows: in addition to logging the
document, each p:message and p:assert is evaluated once for each document
in the order they appear as children of p:log.

A p:message simply outputs its text content as a message. That could be
to STDERR or to a dialog box or a log file, implementation defined.

A p:assert evaluates the effective boolean value of the test expression.
If the expression is true, nothing happens. If the expression is false,
the text content of the message is output per p:message and an exception
is raised. (Open question: should it be possible to catch that exception
in a p:try; probably.)

I think this would all be much more useful if it was possible to output
something about the state of the system. I propose that variable references
are interpolated in p:message/p:assert messages. We could go even further
and say that the text is an XPath expression, but that will be a little
weird as you'll have to quote strings and use concat a lot.

And, if we're going to interpolate variable references, I propose that
we define a few magic ones:

  $p:uri - the base URI of the document being logged
  $p:count - the number of the document being logged

Maybe more. We should probably think about what makes the most sense here,
expression or interpolation. I can see both sides, I think.

                                        Be seeing you,
                                          norm

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