Change the spec of p:message?

[xatapult]

AFAIK p:message was introduced as an easier and more flexible way to send messages to the console, as a replacement/enhancement of the standard message attribute.

Currently the spec says for p:message: the result of evaluating the select option is serialized and made available

Serialization of a string value means: putting quotes around it. So if I say:

<p:message select="Starting computation at {current-dateTime()}"/>

I get my "Starting computation ..." message quoted on the console. That's not what I want and I also think that's not what was intended.

So I think we should change/modify the spec a little to get the messages come out as just strings. Something like (this is just a proposal):

the result is all items in the select option turned into a string and concatenated
Items that can't be turned into a string result in an error
Or:
Items that can't be turned into a string are serialized implementation-defined

What I mean with "turned into a string" is the using the string() function on them. But probably there is a better way of expressing this.

[ndw]

I think we can add even more clarity:

If the result of evaluating the message expression is a sequence of items, we output the items separated by , .

For each item:

1. If it's an atomic value, we output its string value.
2. If it's a map or array we serializing with map{'method':'json', 'indent':true()} and output that
3. If it's a node, we serialize with map{'method':'xml', 'indent':true()} and output that.
4. If it's binary, the results are implementation defined.

[wendellpiez]

In this proposal: assuming a loose attribute node is still an error?

Aside: does it make no sense for p:message to have @serialize ? { 'method': 'text' } being one option among many (and perhaps a default)?

Even further aside: it would make even less sense to bind a port to p:message, i.e. that is what p:output is for?

[xatapult]

I think its not very useful to separate items in select by a ,, given its nature and use-case.

My proposal would be to use either no separator (just concatenate), or, better, consider multiple items as separate calls to p:message. This means that:

<p:message>
  <p:with-option name="select" select="('A', 'B')"/>
</p:message>

Is the same as:

<p:message select="A"/>
<p:message select="B"/>

[ndw]

I proposed , because I mis-remembered what XSLT uses as the default separator (#headdesk). XSLT uses a single space. I think using a space would be more consistent with user expectations.

If you don't want a separator, don't output a sequence. You can always construct the expression so that it joins the items together however you want.

You're proposing to use 
 as the separator. I suppose I could live with that, but I'd prefer a space.

[ndw]

@wendellpiez yes, a loose attribute is still an error. The p:message step exists to make conditional messages easier to manage. It's always an identity step. The select on p:message isn't a select attribute, in the sense of select on, for eample, p:with-input, it's an option named select. (There was debate about whether or not that was going to be confusing.) So if you want a different context item for your message, you don't need another port, you can do this:

<p:message>
  <p:with-option name="select" select="local-name(/*)">
    <p:inline><doc/></p:inline>
  </p:with-option>
</p:message>

The point of the select option is to print a message on the console; I don't think we need to support user-defined serializations for it.

[wendellpiez]

Hm. p:message/@select accepts item()* but for p:*/@message the spec has :

It's [sic] value is treated as an attribute value template (irrespective of any enclosing [p:]expand-text setting)

Leaving the confusing part aside, this is not item()*, and it leaves open the question of what should happen with sequences or non-string objects on p:message/@select.

I'd be open to an option that worked exactly like @message (as less confusing than a select that is really just an option named "select") -- although p:message/@message might be going a bit far. Is it too late to call the step p:announce or something?

Assuming these ideas are no-go, and even if not, I think Norm's spec so far would be workable. Mainly I mention the 'text' mode serialization because (a) it already does the right thing (for text nodes and arguably for any XML), and (b) is also called 'serialization'.

[ndw]

I'm not sure what we have is exactly what we would have done if we'd thought it all through from the beginning. The [p:]message attribute on a step is not an option. It's an attribute with a value that's an AVT. All AVTs boil down to string values, so there's nothing much to be said about that. And, observe, you can't change the context item for that AVT.

For p:message, the step, the goal was to make it easier to have conditional messages, which you can't practically do with [p:]message the attribute. If you're going to have a step just for doing messages, it makes sense to be a bit more flexible with the context item for the message. Making it a p:option provides all the machinery to do that for free. And select on p:message, the step, is pretty straightforward and intuitive, but also a bit more subtle than you might first imagine.

I don't think there's any scope here for sweeping changes, just tidying up the details so that implementations produce the same messages and messages that users find most useful.

[wendellpiez]

@ndw thanks for the explanation and the rationale. Accepting we can't go backwards to go forwards, everything you say makes sense.

As for p:message/@test, is this functionally no different from a parent p:if/@test, or is there anything more/special?

Accepting that the value of @select can be an arbitrary sequence, I do think it's important to be able to emit those console messages without extra quotes or XML escaping ...

[wendellpiez]

Testing Norm's patience, but the separator could be provided with a @separator with a default value, as in XSLT.

[ndw]

It's just simpler, instead of:

<p:if test="ex:moonIsFull()">
  <p:identity message="Ahwoooo!"/>
</p:if>

You can say:

<p:message select="'Ahwoooo!'" test="ex:moonIsFull()"/>

And it has the ability to change the context item for the message, which you can't do with p:if/p:identity. (I mean, you could do it by having a separate step to construct the message that you then use in p:identity, but that only illustrates the simplification with more emphasis.)

Re: @separator: yes, we could. But we could also not. :-) Really, this is mostly a step for debugging and informing users of progress. I expect sequences are in the less than 1% case. Sequences where you care about the separator, in the less than 1% case of that. So if you're in the 0.1%, you can do it yourself:

<p:message select="string-join(ex:mySequenceExpression(), ', ')"/>

[ndw]

On further consideration, I think @xatapult had a good point about sequences. If we say each item in the sequence is a separate message, that's easy to explain, entirely reasonable behavior, and it obviates us from any requirement to argue about the separator or whether or not a separator option is required.