528bis element to map

[michaelhkay]

Supersedes #529
Fix #528

Coming back to this after a long gap, I have redrafted the proposal. I've tried to take as many of the comments into account as possible, but I'm aware that I haven't responded to them all.

[ChristianGruen]

I would still be interested in feedback on some of the comments I raised in #529 (comment) (it’s been a while ago, though):

1. Do you think we could drop the [normalize-space()] predicates?
2. What about merging some of the patterns (simple, simple-plus (extended?), record, mixed, and a custom function)?
3. (The most difficult one, probably): Could it be an option to define the function for a single node() input, to be able to write fn:xml-to-map(doc('regular.xml')?

[michaelhkay]

I did review all the comments on #529 and implemented those that I thought were straightforward, but there are certainly others that are worth discussing.

I felt that the [normalize-space()] predicates were the right way (in the absence of a schema) to distinguish elements with element-only content from elements with mixed content. You really want to discard whitespace text nodes in the conversion if it's element-only content, and not otherwise.

I looked at merging some of the layouts but I felt that there were signifcant distinctions, and you want to give users this level of fine control.

I agree it would be convenient for users to allow the input to be a document node rather than an element, but I wasn't sure what to say if the document node doesn't have a single element child.