Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
This error reads:
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?
Stipulating strict RFC 3986 compliance might force you to reject manifest entries with unescaped UTF-8 octets or with
You need to apply some URI normalization to
Only certain things that are known to be problematic may be flagged as an error, like
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.
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
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?