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

Inconsistent format attributes #293

Closed
ndw opened this issue Dec 15, 2019 · 4 comments
Closed

Inconsistent format attributes #293

ndw opened this issue Dec 15, 2019 · 4 comments
Assignees

Comments

@ndw
Copy link
Collaborator

@ndw ndw commented Dec 15, 2019

On p:archive, format defaults to zip.
On p:archive-manifest, it's optional and the processor is expected to work it out.

I think the format attribute should be treated consistently on these two steps. I don't feel strongly about which approach to take, but I'm guessing that the p:archive-manifest way is a little less typing for users.

@gimsieke

This comment has been minimized.

Copy link
Contributor

@gimsieke gimsieke commented Dec 15, 2019

I think this was a deliberate decision. With p:archive you typically create a fresh archive, and you need to specify its format. If you omit it, you get a Zip. With p:archive-manifest, you extract a manifest from an existing archive. From a pipeline author’s perspective, it is preferable that the implementation infer the archive format for p:archive-manifest, rather than defaulting to zip when no explicit format option is given. So the perceived inconsistency is justified IMO (or there is no inconsistency because the premises aren’t the same).

@ndw

This comment has been minimized.

Copy link
Collaborator Author

@ndw ndw commented Dec 15, 2019

Okay, but as written, if you do provide an archive and it isn't a zip archive, you'll get an error if you omit the format option even if the archive format could have been inferred from what was provided.

I'd be happier to make the steps consistent, allow the processor to infer the archive format in both cases, and simply say that if no archive is provided and no format is specified, the format "zip" is implied.

@gimsieke

This comment has been minimized.

Copy link
Contributor

@gimsieke gimsieke commented Dec 15, 2019

Okay, but as written, if you do provide an archive and it isn't a zip archive, you'll get an error if you omit the format option even if the archive format could have been inferred from what was provided.

Is it? “If no format option is specified or if its value is the empty sequence, the archive's format will be determined by the step, using the content-type document-property of the document on the source port and/or by inspecting its contents.”

Ah, you are referring to p:archive.

I'd be happier to make the steps consistent, allow the processor to infer the archive format in both cases, and simply say that if no archive is provided and no format is specified, the format "zip" is implied.

Yes, that’s the most user-friendly way. Let’s spec it that way.

@ndw ndw self-assigned this Dec 15, 2019
@ndw

This comment has been minimized.

Copy link
Collaborator Author

@ndw ndw commented Dec 19, 2019

Fine

@ndw ndw closed this Dec 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.