Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can an XProc 3 pipeline handle any XDM 3.1 sequence? #808

Open
martin-honnen opened this issue Jun 2, 2019 · 1 comment

Comments

Projects
None yet
2 participants
@martin-honnen
Copy link

commented Jun 2, 2019

The current spec in http://spec.xproc.org/master/head/xproc/#documents.9 states:

Some steps like p:xslt, p:xquery etc. create new XDM instances

and then gives rules on how XDM instances are to be "converted into documents before appearing on the output port of that particular step".

However, these rules do not seem to cover all type of XDM values/types possible since XPath 3.1, the first three rules deal with nodes, but the wording only seems to handle single nodes (i.e. "is a single text node", "is any other node", "is a document node") without covering sequences of nodes or arrays of nodes or maps of nodes or any mixture of that.

The last rule talks about creating a JSON document for "a map, array or any atomic value" and again fails to explain what happens with sequences of maps, sequences of arrays, sequences of atomic values or any mixtures of sequences/maps/arrays/atomic values that don't fit into a JSON representation.

So my general question for clarification is whether an XDM step in an XProc pipeline can create any XPath 3.1 sequence respectively an XPath 3.1 value of any possible sequence type, including, for example, array(node())*, map(xs:string, node())*.

Also, what would be the "document" representation for such types that don't fit the concept of a JSON document?

@ndw

This comment has been minimized.

Copy link
Contributor

commented Jun 10, 2019

Per #811 , we'll clarify how sequences of items are turned into sequences of documents.

Consensus: the "JSON" documents returned in this case are allowed to contain nodes; the "adaptive" serialization method will turn these into strings; the other methods will fail.

Basically, internally, we treat "JSON" as what XDM allows in maps. This may result in problems for serialzation or for extension steps that want to use other JSON libraries. The same is true of arrays.

Somewhere in the spec we need to spell out the fact that we align "JSON" with XDM maps and arrays.

After much discussion: consensus is we will allow these extensions in the output between steps; maybe have options on processors to help debug this case; serialization will fail in some cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.