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

fn:has-attributes #964

Closed
ChristianGruen opened this issue Jan 23, 2024 · 5 comments
Closed

fn:has-attributes #964

ChristianGruen opened this issue Jan 23, 2024 · 5 comments
Labels
Feature A change that introduces a new feature Propose Closing with No Action The WG should consider closing this issue with no action XQFO An issue related to Functions and Operators

Comments

@ChristianGruen
Copy link
Contributor

Trivial (motivated by a user request):

As there is an fn:has-children function, it seems surprising that there is no fn:has-attributes function.

I would suggest…

  • adding this function to the spec, or
  • indicating in a note (for fn:has-children) why this function is missing.
@ChristianGruen ChristianGruen added XQFO An issue related to Functions and Operators Feature A change that introduces a new feature labels Jan 23, 2024
@michaelhkay
Copy link
Contributor

The has-children() function was introduced specifically to support XSLT streaming, as a way of testing (by a single-token lookahead) whether children exist, without actually swallowing them as the equivalent exists(child::node()) would do. It was then moved from XSLT into XPath (along with other streaming-oriented things such as innermost() and outermost()) on the basis of "no needless differences".

The functionality of has-attributes() can be readily achieved using exists(@*) and I really see no need for a special function to do that.

@ChristianGruen
Copy link
Contributor Author

The has-children() function was introduced specifically to support XSLT streaming, as a way of testing (by a single-token lookahead) whether children exist, without actually swallowing them as the equivalent exists(child::node()) would do.

Wouldn’t that be a typical task for an optimizer (rewriting exists(node()) to an internal has-children() check)?

The specification states that the function has “general utility as a convenience function”. I think the argument would also be valid for an attribute function.

After all, it probably takes more time to talk about the function than just adding or ignoring it, so… I have no strong opinion.

@michaelhkay
Copy link
Contributor

michaelhkay commented Jan 23, 2024

Wouldn’t that be a typical task for an optimizer (rewriting exists(node()) to an internal has-children() check)?

We made a decision (rightly or wrongly) that XSLT streamability shouldn't depend on optimization rewrites, in order to make the rules fully interoperable.

The statement that "the function has general utility as a convenience function" clearly indicates, to someone experienced in reading standards documents, that the WG knew the justification was weak; features don't attempt to justify themselves otherwise.

@michaelhkay michaelhkay added the Propose Closing with No Action The WG should consider closing this issue with no action label Jan 30, 2024
@michaelhkay
Copy link
Contributor

I don't think this function adds much value and I propose we turn down the suggestion.

@ndw
Copy link
Contributor

ndw commented Feb 6, 2024

The CG agreed to close this issue without action at meeting 064

@ndw ndw closed this as completed Feb 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature A change that introduces a new feature Propose Closing with No Action The WG should consider closing this issue with no action XQFO An issue related to Functions and Operators
Projects
None yet
Development

No branches or pull requests

3 participants