The text for fn:serialize says:

"The serialization process will raise an error if $arg is an attribute or 
namespace node."

It fails to include what error that is and it if it mentions these un-serializable types, it stands to reason that the text should also mean that a function item, map or array will lead to a serialization error (or if not: how should they be treated?). Reasonably, SENR0001 or XPTY0004 could be raised.

The tests serialize-xml-002, seralize-xml-010 - 012 all expect error SENR0001, but the text above says "an error". Could we perhaps rephrase it to point to the corresponding error in the SER31 spec?

The last sentence in the Error section is:

"If any serialization error occurs, including the detection of an invalid value for a serialization parameter as described above, this results in the fn:serialize call failing with a dynamic error."

This makes the earlier sentence rather redundant. Also, I'd argue that perhaps this should point out that "a dynamic error" is an error from the SER31. Unless this is intended to be implemention-defined/dependent, in which case I think we should say so. The tests expect specific errors.

My suggestion for a fix would be something like (replace both statements with one):

"The serialization process will raise an error if $arg is an attribute or 
namespace node, or if it is a function item [SENR0001]. If any other serialization error occurs during the serialization process as described in [SER31], that error is propagated in an implementation-dependent way and the fn:serialize call will fail with a dynamic error."


This would leave it sufficiently open (as not to violate the current status of "an error") while strongly suggesting to use the serialization error codes (which leads to better interoperability).