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

p:unarchive needs another fix #298

Closed
xml-project opened this issue Dec 18, 2019 · 5 comments
Closed

p:unarchive needs another fix #298

xml-project opened this issue Dec 18, 2019 · 5 comments
Assignees

Comments

@xml-project
Copy link
Contributor

@xml-project xml-project commented Dec 18, 2019

In the specs we say:

The base URI of an unarchived document appearing on the result port is:
If the relative-to option is present: Function p:urify() is called with the value of this option as second parameter ($basedir) and with the relative path of this document as it was in the archive as first parameter
If the relative-to option is not present: Function p:urify()is called with the value of the base URI of the archive appended with a “/” as second parameter ($baseDir) and the relative path of this document as it was in the archive as first parameter
It is a dynamic error (err:XD0064) if the option is not a valid URI according to [RFC 3986].

The case not covered is: relative-to is not set and the archive does not have a base URI: Remember we changed p:set-properties so now a pipeline author can explicitly remove a document's base URI. Example:

<p:load href="uri-of-archive" />
<p:set-properties properties="map{}" /> <!-- removes base uri -->
<p:unarchive />

What do we do in this case: (a) Raise an error or (b) use the step's base URI?

@ndw

This comment has been minimized.

Copy link
Collaborator

@ndw ndw commented Dec 18, 2019

I think it's an unlikely situation. If we use the base URI of the step, it won't be an error but it might be unexpected. If we make it an error, the pipeline author can work around it by setting the base URI. Flip a coin?

@xml-project

This comment has been minimized.

Copy link
Contributor Author

@xml-project xml-project commented Dec 18, 2019

I think it's an unlikely situation.

Yes it is. But I do not know how to handle this case. The specs suppose a base URI is present, but this need not to be the case as I showed.

If we make it an error, the pipeline author can work around it by setting the base URI.

Yes, and this would be my reason for an error. If an author explicitly deletes the base URI of the archive, he did something wrong if he later wants to unarchive.

@ndw

This comment has been minimized.

Copy link
Collaborator

@ndw ndw commented Dec 18, 2019

I think that's a convincing reason to make it an error.

@xml-project xml-project self-assigned this Dec 18, 2019
@ndw

This comment has been minimized.

Copy link
Collaborator

@ndw ndw commented Dec 19, 2019

Agreed. If relative-to isn't given, and the source archive doesn't have a base URI, that's an error.

@xml-project

This comment has been minimized.

Copy link
Contributor Author

@xml-project xml-project commented Dec 21, 2019

Fixed with #304

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.