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

json-merge? #180

Open
ndw opened this issue Jul 29, 2019 · 12 comments

Comments

@ndw
Copy link
Collaborator

commented Jul 29, 2019

Shouldn't there be a json-merge step that takes a sequence of objects and merges all their keys into a single object? My thinking is the keys from the second and following objects replace the keys from the preceding objects.

@ndw

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 29, 2019

And, no, for the record, I don't think that adding this step would necessarily mean we'd want to move the JSON steps back into a separate spec!

@xml-project

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2019

As you might remember, I was very much in favour for more JSON related steps. But we decided to have only those JSON steps, which can not be done with XPath. This is true for p:json-join() because it relies on the order of entries (not guaranteed by XPath).
At a first thought I would expect JSON merge to be done this XPath? What do I miss?

@ndw

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 29, 2019

I haven't worked very much with arrays and maps in XPath. It's not immediately obvious to me what XPath expression can consume a series of maps and merge them. It was the ordering that made me think of the need for the step, actually. The keys in object 2 should override the keys in object 1, 3 should override 2, etc.

If it can be done in XPath, we should at least publish the expression that does it. Maybe we should do the same for other common operations.

@xml-project

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2019

Ordering with override is a good point. I did not see this. So we need this step.

If it can be done in XPath, we should at least publish the expression that does it. Maybe we should do the same for other common operations.

You do not have to convince me. My processor will ship with a serious of JSON related steps so you can do JSON operations "the XProc way" (and not have to bother with complex XPath expressions).

May be we should discuss this point again at one of our next f2f.

@gimsieke

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2019

No objection. We have always intended to publish XProc-implemented steps. More XPath-implementable JSON steps could be part of a p:library (that a processor can either import by default without requiring an explicit p:import, or that can be imported by a pipeline author from a canonical URI that will be resolved by the processor).

But if we do so, it’d probably be better to have them in a separate spec (and not to make the XProc/XPath implementation mandatory if a processor chooses to implement these steps in another way). I’m not advocating the return of the JSON steps spec but a separate XProc-implemented steps spec.

@xml-project

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2019

We have always intended to publish XProc-implemented steps.

I was not talking about a XProc-/XPath-implemented library of JSONSteps, but about native steps as a vendor specific extension library. So there is -at least from my point of view- no need for spec.

@gimsieke

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2019

But wouldn’t it be nice if these extensions were interoperable? Historically this is something for EXProc. But since everything from EXProc has been integrated into XProc 3 now, we might consider harmonizing the extensions as part of the XProc 3 family of specs. It may still develop at its own pace, independently from the standard steps spec.

@ndw

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 29, 2019

I think JSON is important enough and significant enough that if there's a useful vocabulary of steps for manipulating it, we should spec them and they should be interoperable. I'm not too fussed about whether they're implemented in XProc or in the implementation.

@xml-project

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2019

But we had this discussion before, hadn't we?

@ndw

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 29, 2019

Welcome to standards committees. :-)

There's a constant tension between keeping things small, keeping this simple, etc. and making something that's easy for users to use. I think, on reflection, we may have made the wrong choices about the JSON steps.

@xml-project

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2019

Welcome to standards committees. :-)

Thanks you. ;-))
As I said before, I think it is right to have JSON related steps in the standard library. But: I think we are waisting our time if we spell those steps and then decide to have them not in the specs.

You might say that's life in a standard committee too. But my motivation to work on it is not boosted by this insight.

@ndw

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 29, 2019

I understand. I think we do reasonably well managing churn as a group, but the closer we get to the finish line, the harder it becomes.

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