p:unarchive needs another fix

[xml-project]

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]

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]

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]

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

[ndw]

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

[xml-project]

Fixed with #304