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

Share variables with XSLT/XQuery libraries #52

Open
xatapult opened this issue Jun 19, 2024 · 4 comments
Open

Share variables with XSLT/XQuery libraries #52

xatapult opened this issue Jun 19, 2024 · 4 comments

Comments

@xatapult
Copy link
Contributor

xatapult commented Jun 19, 2024

From a software engineering point of view it would be very welcome to be able to access global variables (and parameters?) in an XSLT/XQuery library, once imported.

I often have (magic) values that I use both in the XSLTs (used in the pipeline) and in the pipeline itself. For instance special values for attributes. It would be nice to specify these only once.

@ndw
Copy link

ndw commented Jun 19, 2024

Do you mean when you use p:import-functions? (If you don't mean that, then I'm not sure what you do mean.)

Off the top of my head, what I'd suggest is defining functions that return those values.

@xatapult
Copy link
Contributor Author

Do you mean when you use p:import-functions? (If you don't mean that, then I'm not sure what you do mean.)

Yes.

Off the top of my head, what I'd suggest is defining functions that return those values.

When you have a lot of these kinds of values (and I sometimes have), that's not a viable option. And anyway, it's a coding "trick". IMHO, when technically possible, we should avoid these.

@gimsieke
Copy link

I’d also recommend to use functions for that use case. Lots of values can be returned as a map.

@xatapult
Copy link
Contributor Author

Well... yes that would of course be possible. But it would also mean adding additional code to your XSLT, sometimes a substantial amount. With all the hazards of double updates and/or forgetting something.

IMHO there's nothing theoretically against this idea. Why not make things easy for XProc users? There might however of course be very valid technical reasons why it isn't viable... I'm not an implementer.

XProc is no longer for toy problems only. I think we have to take into account that you can build very, very complicated systems with it (I did). Anything that makes the software-engineering easier is most appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants