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

Clarification p:tee needed (remove p:tee) #101

Closed
eriksiegel opened this issue May 30, 2019 · 8 comments

Comments

Projects
None yet
5 participants
@eriksiegel
Copy link
Contributor

commented May 30, 2019

p:tee has sequence source and result ports, but only a single href option to write a document to. What happens when there are multiple documents on the source port?

@eriksiegel

This comment has been minimized.

Copy link
Contributor Author

commented May 30, 2019

My preferred solution would be to simply store only the first document appearing on the source port.

@gimsieke

This comment has been minimized.

Copy link
Contributor

commented May 30, 2019

Alternatively, interpret href as a directory if there are multiple documents and store the individual documents below this directory, with implementation-dependent names (for ex., 1.xml, 2.json, …; or use the filename parts of their base URIs, if unique; or disambiguate by prepending a sequence number; etc.).
I see some use in storing them all.

@eriksiegel

This comment has been minimized.

Copy link
Contributor Author

commented May 30, 2019

@gimsieke I have no use-case for more-than-one-doc but I can see your point. What would be your preferred algorithm for the filenames? And what do the implementers @ndw and @xml-project think about this?

@gimsieke

This comment has been minimized.

Copy link
Contributor

commented May 30, 2019

The algorithm may be implementation-defined, but if we were to suggest something I’d say: Use the filename part of the base URI, possibly disambiguated by prepending them with a sequence number and a separator like _.
In contrast to what I said above, it shouldn’t depend on the number of input documents whether href is interpreted as a directory. It’s probably better to treat it as a directory if and only if it ends with a slash. This means we need to raise a dynamic error if there are multiple source documents and href doesn’t end in /.

@Conal-Tuohy

This comment has been minimized.

Copy link

commented May 30, 2019

Alternatively, p:tee could have non-sequence ports, and a programmer who wanted to use it with a sequence could wrap it in a p:for-each, and compute a distinct @href dynamically within the p:for-each.

@xml-project

This comment has been minimized.

Copy link
Contributor

commented May 30, 2019

No opinion here, but two comment:
(1) What do we say about option serialization in port source has a mixed content (text, json, xml ...)?
(2) If we want an algorithm for calculating the filename, I think it should be controllable by pipeline authors via additional options.

@eriksiegel

This comment has been minimized.

Copy link
Contributor Author

commented Jun 3, 2019

Ok, after some thinking, my opinion:

  1. I asked for p:tee because it is such a marvelous debugging aid
  2. There is only one option to pass in serialization parameters
  3. Given the above, lets keep thing simple: First document passing through is serialized. href is not a directory name but a filename
  4. If you really need multiple documents, wrap it in a p:for-each as @Conal-Tuohy writes
@ndw

This comment has been minimized.

Copy link
Collaborator

commented Jun 10, 2019

Consensus: change p:store and other steps to support outputting the input document and the URI; remove p:tee. (This issue is now about removing p:tee). See also #106

@ndw ndw changed the title Clarification p:tee needed Clarification p:tee needed (remove p:tee) Jun 10, 2019

@xml-project xml-project self-assigned this Jun 14, 2019

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.