Reconsider the content type of "atomic values"?

[ndw]

If you create, for example, a p:xquery step that produces a string, that string gets labeled application/json because it's a simple atomic value.

But that means if you subsequently try to use that document where a text document is expected (for example p:ixml or p:text-tail, etc.), you'll get an error.

Requiring the user to insert p:cast-content-type steps in between seems awfully tedious.

My temptation is to suggest that if an application/json document is passed where a text document is expected, and that JSON document is a simple atomic value (as opposed to a map or array), then we automatically cast it to a text document by serializing the atomic value.

But I don't know if that'll have other consequences we won't like...

I suppose an alternative approach would be to say that if a step produces a simple atomic value that's an xs:string or xs:untypedAtomic, we label it text/plain instead of application/json.

Or maybe something else I haven't thought of...

[djbpitt]

A few more data points:

<p:cast-content-type> converts CR and LF to the strings "\r" and "\n", respectively, which may or may not be correct for casting JSON as text, but it's unwanted here.

The following appears to work (thanks, @ndw), but it feels like a hack when I consider that I had created a plain-text document in the first place:

<p:identity>
  <p:with-input>
    <p:inline content-type="text/plain">{.}</p:inline>
  </p:with-input>
</p:identity>

[ndw]

It also puts the string in quotes which you surely don't want.

[ndw]

On reflection, changing the content type of a string result would be backwards incompatible and could break existing pipelines.

Changing the interpretation of application/json in this context would make something that was an error no longer an error. That's safer, though still technically backwards incompatible.

We could make this behavior change dependent on the version, he says with a deep sigh.

[djbpitt]

Currently specifying that a result is text with a content-type attribute is ignored. That's confusing, and perhaps a design flaw; if it doesn't work, should it be allowed? Shouldn't it either work or raise an error? But what if it weren't ignored? The default behavior wouldn't change; how important is it to preserve the behavior when users specify text/plain explicitly and, against reasonable expectations, without effect?

I imagine that allowing an application/json result might be helpful if an operation creates numbers that should emerge with numeric, rather than string, properties, and application/json would allow that. Whether that should have been the default would be a separate issue, and I understand that changing default behavior, including retrospectively questionable default behavior, should be avoided. From that perspective aren't there three questions:

1. Should it be possible to get text/plain when that's what you need and application/json when that's what you need? (I think yes.)

2. If so, what should the default be? (I think we're locked into application/json as the default for backward compatibility reasons.)

3. Also if so, how can we best allow both types of result in an intuitive way and with minimal disruption? (Can we begin to honor a content-type specification on the result of text/plain, instead of ignoring it?)

[djbpitt]

Achim just explained to me that I can force the <p:xquery> step to return plain text by wrapping the result in a constructed text node:

<p:xquery>
  <p:with-input port="query">
    <p:inline content-type="text/plain">text{{substring(.,2)}}</p:inline>
  </p:with-input>
</p:xquery>

Whether the fact that the expression without the text-node wrapper returns application/json, rather than text/plain, is, I think, a separate question, but in the meanwhile, Achim's suggestion points to a legible and light-weight strategy for getting the output I need.

[ndw]

How might this work: a JSON document consisting of a single string arrives on a port.

1. If the port accepts only text, convert the string to a text node.
2. If the port accepts json plus other things, do nothing.
3. If the port accepts text and other things, (but not JSON), convert it.
4. If the port does not accept text, error.

This is all very confusing. V.next?