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

Replace p:load-directory-list with p:load-uris #96

Open
ndw opened this issue May 23, 2019 · 6 comments

Comments

Projects
None yet
3 participants
@ndw
Copy link
Collaborator

commented May 23, 2019

Tangential to #89 ...

I dislike p:load-directory-list. It's hugely redundant with p:directory-list which is already complicated. It feels like what we really want is a step which takes a directory list as an input and loads all the files within it. That would have the added benefit that a user could construct the input in some other way and load a bunch of URIs without making a for-each loop containing p:load.

Perhaps:

<p:declare-step type="p:load-uris">
    <p:input port="source" content-type="xml"/>
     <p:output port="result" content-type="any"/>
</p:declare-step>

With the semantic that it walks over the source input document and attempts to load each &lt;p:file/&gt; that it finds, ignoring all other content.

@gimsieke

This comment has been minimized.

Copy link
Contributor

commented May 23, 2019

Another alternative: No additional step but rather an additional option and an additional output port for p:directory-list:

<p:directory-list href="file:///home/jane/" recursive="true" 
  include-filter="\.(png|jpg)$" resources="true"/>

returns the listing on the result port and its c:file-related resources (PNG and JPEG images below Jane’s home dir in this case) on the resources port.
The resources port is always present, but it doesn’t return any documents for resources="false", which is the default.

@ndw

This comment has been minimized.

Copy link
Collaborator Author

commented May 23, 2019

Well, sure, I suppose. But that makes p:directory-list even more complicated. I'm trying to reduce the problem to the composition of two simpler steps.

@gimsieke

This comment has been minimized.

Copy link
Contributor

commented May 23, 2019

From a user’s angle, another port and option make p:directory-list only marginally more complicated.

One question to ask ourselves is whether p:load-uris will likely be used outside a context where p:directory-list is already employed. I suspect it won’t, and therefore we can cram them into a single step, thereby making it less complicated for users.

This is probably a philosophical “monolithic vs. composable” discussion on par with “init vs. systemd” in the Linux realm. I’m in the non-monolithic init camp btw, but here I’m more in the “turn p:directory-list into an almost operating-system-like monolithic moloch” camp.

@ndw

This comment has been minimized.

Copy link
Collaborator Author

commented May 23, 2019

Your inconsistency has been noted and will be held against you in the future.

@eriksiegel

This comment has been minimized.

Copy link
Contributor

commented May 23, 2019

Why don't we skip p:load-directory-list alltogether? It's just syntactic sugar over a p:for-each/p:load structure...

@ndw

This comment has been minimized.

Copy link
Collaborator Author

commented May 23, 2019

Editor's call from 23 May: Erik supports p:load-uris.

Some discussion of the fact that this is syntactic sugar for a loop or viewport over the output of the p:directory-list step

Apparent onsensus: get rid of p:load-directory-list, we can have p:load-uris as a step implemented in XProc.

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.