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

Error XD0064 is void #248

Closed
xml-project opened this issue Oct 18, 2019 · 7 comments
Assignees

Comments

@xml-project
Copy link
Contributor

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

This error reads:

It is a dynamic error if the c:entry/@href attribute in a p:archive step manifest is present and its value is not a valid xs:anyURI.

or

It is a dynamic error (err:XD0064) if the href URI is not a valid xs:anyURI.

The specs on xs:anyURI define it as matching the XML char production. This means (to my reading) that this error could never to raised, once on XProc document is parsed. Right?

I propose therefor to say, that @href must by a valid URI par rfc3986. Does this make sense to anyone?

@ndw

This comment has been minimized.

Copy link
Collaborator

@ndw ndw commented Oct 18, 2019

Are we really going to insist that implementations test the value?

@gimsieke

This comment has been minimized.

Copy link
Contributor

@gimsieke gimsieke commented Oct 18, 2019

Stipulating strict RFC 3986 compliance might force you to reject manifest entries with unescaped UTF-8 octets or with file:/home instead of file:///home although they might just resolve fine on most users’ machines. Postel’s law suggests that we accept these unorthodox yet widespread shortcuts. If they don’t resolve to resources, you are free to give users a hint that non-conformance with RFC 3986 might cause the issue.

You need to apply some URI normalization to c:entry/@href before comparing it to the base-uri document property of the incoming documents. Things like FILE:/c:/file:///C:/, file:///home//dave/foo/../barfile:///home/dave/bar, etc.

Only certain things that are known to be problematic may be flagged as an error, like file://foo/bar on Unix-like systems (on Windows it’s ok; foo is then interpreted the host name component in a UNC path).

We can think about keeping the error code for situations when an implementation deems a purported URI “too far off”, but the criteria it applies may be implementation-dependent.

@xml-project

This comment has been minimized.

Copy link
Contributor Author

@xml-project xml-project commented Oct 19, 2019

I think we should follow the XPath and XQuery function definition and define href on p:load, p:document, p:with-input, p:input and p:output (hope I did not miss one) as an instance of xs:string and raise a dynamic error, if this string is not a valid URI reference. (@gimsieke XPath is strict here, so I think we could dare to be strict to.)

I am not sure how to deal with the href in the manifest document of p:archive because it serves a double of either identifing a document contained on port source. If no such document is provided, the specs say,

the value of the href attribute is interpreted as a URI and the document is loaded from this location

So here it is clear to me, that it has to be a valid URI reference and that it would be user friendly to raise an error stating, that the load failed because the uri is defective.

Does this make sense?

@xml-project

This comment has been minimized.

Copy link
Contributor Author

@xml-project xml-project commented Oct 20, 2019

I think @ndw is right. Lets just remove this error. It is up to the pipeline author to provide a URI that is valid from the used file system.

@xml-project

This comment has been minimized.

Copy link
Contributor Author

@xml-project xml-project commented Nov 7, 2019

But see @gimsieke's comment arguing for the opposite. (If I understood it right). If not, I am pretty sure however that this comment is related to this issue.

@gimsieke

This comment has been minimized.

Copy link
Contributor

@gimsieke gimsieke commented Nov 7, 2019

IIRC we decided at our last call that we want to have a check (and an autocorrection), potentially deferred to when the processor is actually reading or writing from/to a URI.

@ndw

This comment has been minimized.

Copy link
Collaborator

@ndw ndw commented Nov 9, 2019

Per discussion at the f2f, we will change the message to say that it has to be valid by the RFC rather than by xs:anyURI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.