This is still new stuff for me, but it seems like a bug. I'd expect
string($node) and string(data($node)) to return the same result for any node
with a simple type, because fn:string should atomize the node in much the same
way fn:data does. In other words I'd expect it to behave pretty much like an
element with a defined simple type.
element test {
attribute xsi:type { "xs:integer" },
1 }
! (
string(.),
string(data(.)))
! xdmp:describe(.)
=> "1", "1"
Of course if the node is complex then fn:string still works but fn:data will
throw XDMP-NONMIXEDCOMPLEXCONT. But number-nodes and boolean-nodes should be
simple — right?
xdmp:type(number-node { 1 })
=> integer
xdmp:type(boolean-node { true() })
=> boolean
-- Mike
> On 9 Feb 2015, at 13:24 , Joe Bryan <[email protected]> wrote:
>
> Hi All,
>
> I've been playing with native JSON in XQuery, and was surprised to see that
> fn:string() returns a zero-length string when passed a number-node or
> boolean-node. On the contrary, an explicit cast expression works as expected.
> The documentation for fn:string($arg) states: "If $arg is a node, the
> function returns the string-value of the node, as obtained using the
> dm:string-value accessor."
>
> Is this a bug, or simply a consequence of the JSON node hierarchy?
>
> Thanks.
>
> -jb
>
> Here's a few test-cases:
>
> 1,
> fn:string(1),
> number-node{1},
> fn:string(number-node{1}),
> fn:string(fn:data(number-node{1}))
> ,
> 1,
> 1 cast as xs:string,
> number-node{1},
> number-node{1} cast as xs:string
> ,
> fn:true(),
> fn:string(fn:true()),
> boolean-node{1},
> fn:string(boolean-node{1}),
> fn:string(fn:data(boolean-node{1}))
> ,
> fn:true(),
> fn:true() cast as xs:string,
> boolean-node{1},
> boolean-node{1} cast as xs:string
> _______________________________________________
> General mailing list
> [email protected]
> http://developer.marklogic.com/mailman/listinfo/general
_______________________________________________
General mailing list
[email protected]
http://developer.marklogic.com/mailman/listinfo/general
