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

XQFO: Unknown option parameters #1019

Closed
ChristianGruen opened this issue Feb 11, 2024 · 3 comments
Closed

XQFO: Unknown option parameters #1019

ChristianGruen opened this issue Feb 11, 2024 · 3 comments
Labels
Editorial Minor typos, wording clarifications, example fixes, etc. XQFO An issue related to Functions and Operators

Comments

@ChristianGruen
Copy link
Contributor

The current option parameter conventions are:

  1. It is not an error if the options map contains options with names other than those described in this specification. Implementations MAY attach an ·implementation-defined· meaning to such entries, and MAY define errors that arise if such entries are present with invalid values. Implementations MUST ignore such entries unless they have a specific ·implementation-defined· meaning. Implementations that define additional options in this way SHOULD use values of type xs:QName as the option names, using an appropriate namespace.

The obvious consequence is that wrongly typed or unsupported options are not reported as such:

serialize($node, map { 'format': 'html' })

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 of byte-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.

@ChristianGruen ChristianGruen added XQFO An issue related to Functions and Operators Editorial Minor typos, wording clarifications, example fixes, etc. labels Feb 11, 2024
@michaelhkay
Copy link
Contributor

Incidentally, F+O §1.6 still refers to the "function conversion rules" by their old name, with a link to XP31.

@michaelhkay
Copy link
Contributor

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 Q{uri}local strings should be accepted.

@ChristianGruen ChristianGruen added the Tests Needed Tests need to be written or merged label Mar 4, 2024
ChristianGruen added a commit to ChristianGruen/qtspecs that referenced this issue Mar 4, 2024
@ChristianGruen ChristianGruen added the PR Pending A PR has been raised to resolve this issue label Mar 4, 2024
@michaelhkay
Copy link
Contributor

I hit an interesting example today: I wrote a test that did:

csv-to-arrays("a,b,c,d,e,f|p,q,r,s,t,u", 
             map{'row-delimiter':'|',  'select-columns':1 to 3}) 

It's easy to forget that select-columns is allowed on parse-csv but not on csv-to-arrays. Perhaps we should change that; but in the meantime, silently ignoring the option isn't exactly helpful.

@ndw ndw closed this as completed in 3ff6e90 Mar 26, 2024
@ChristianGruen ChristianGruen removed PR Pending A PR has been raised to resolve this issue Tests Needed Tests need to be written or merged labels Mar 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Editorial Minor typos, wording clarifications, example fixes, etc. XQFO An issue related to Functions and Operators
Projects
None yet
Development

No branches or pull requests

2 participants