Comment 3 for bug 1200090

> please explain WHY it makes more sense now.

Because we have JSONiq now, and it's become a central part of the Zorba identity. It's weird (IMHO) to have a module in Zorba that deals with JSON only as strings, rather than data model instances.

> What use cases does the proposed change make simpler?

Any that involve getting JSON back from something (such as the new JSONiq-based http-client module, or the database drivers) and wanting to convert that to JsonML, etc. There are a great deal more ways of getting JSON data model instances than there are of getting JSON strings.

> What cases does it make harder?

If we leave the existing functionality in place (which is what I originally suggested), then nothing would become harder. The trick there is coming up with reasonable function names, since you can't really overload a single function name.

If we eliminate the JSON string functionality entirely (which is what Ghislain suggested), then any use case where you actually have only a JSON string would have one additional step. Also, it's possible that doing this might break streamability (does the module support that currently?).

> If I already have an xs:string, how would I use json-to-xml() with the proposed change?

jx:json-to-xml( jn:parse-json( $mystring ) )