-
Notifications
You must be signed in to change notification settings - Fork 15
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
XQFO: Unknown option parameters #1019
Comments
Incidentally, F+O §1.6 still refers to the "function conversion rules" by their old name, with a link to XP31. |
I'm inclined to agree that unrecognised bare strings should be rejected (but note this ends up being advisory, since implementations can always choose to recognize every string...). QNames and |
I hit an interesting example today: I wrote a test that did:
It's easy to forget that |
The current option parameter conventions are:
The obvious consequence is that wrongly typed or unsupported options are not reported as such:
I think we should still allow proprietary options, but raise errors when an option is neither defined in the specification nor supported by the given implementation. On the one hand, this will help users to spot typos (e.g.,
byte-order-mask
or instead ofbyte-order-mark
). On the other hand, options that are supported by one implementation will be rejected, which feels reasonable to me, as options usually change either the result, or the way how the input is treated.If we believe that this change is too disruptive, we could tolerate entries with
xs:QName
keys.The text was updated successfully, but these errors were encountered: