XQFO Code in the Rules sections

[ChristianGruen]

XQFO Code in the Rules sections

[michaelhkay]

In 3.1 we went for dual exposition in XQuery and XSLT. That was probably a political compromise rather than anything else. In principle it's a bad idea to have two competing normative specifications.

Using XPath everywhere would be nice, but the key problem is that recursive functions in XPath are very cumbersome. Perhaps the best solution to that would be to find a better way of writing recursive functions in XPath. Maybe the answer to that is to add a subset of the XQuery Prolog to the XPath language (perhaps just function declarations and namespace declarations). XPath expressions, as used in XSLT, would still be expressions, with no Prolog, but the XPath specification would define a larger construct (called perhaps an XPath module) containing a Prolog and an Expression.

I don't think there is any fundamental problem with using XQuery as a specification language for the function library. We can use any language we like so long as it has the right data model and is well specified. But for tutorial purposes, it's nice if readers don't have to learn another language.

There's another problem we should be aware of, which is the danger of circular definitions. We should probably be taking more care to classify which constructs are basic and which are derived. Ideally we would define a "core" language containing the basics, and all other constructs would be specified using only this core.

[michaelhkay]

I think it might be useful, if only for our own editorial sanity, if we classified functions, and perhaps syntactic constructs, as intrinsic or extrinsic. Extrinsic functions and constructs should be specified in terms of a "lexical" equivalence that relies only on intrinsic constructs. For example, node-name() is intrinsic; local-name(), namespace-uri(), and name()` are extrinsic.

To avoid too much discontinuity from current practice, extrinsic functions should be defined as follows in order of preference:

(a) where possible, an XPath expression that can be used as the body of the function: for example local-name($node) is local-name-from-QName( node-name($node)).

(b) if that's not possible or convenient, use an XQuery expression.

(c) if the equivalent is recursive or requires supporting functions, express the equivalence using XQuery function declarations. Unless we can come up with a more readable way of expressing recursive functions in XPath, we should avoid them.

We should ideally have some way of checking that we haven't introduced any circularity into the specification.

[ChristianGruen]

Thanks to @dnovatchev's discussion, I had the honor of opening issue #1000.

[dnovatchev]

I think it might be useful, if only for our own editorial sanity, if we classified functions, and perhaps syntactic constructs, as intrinsic or extrinsic. Extrinsic functions and constructs should be specified in terms of a "lexical" equivalence that relies only on intrinsic constructs. For example, node-name() is intrinsic; local-name(), namespace-uri(), and name()` are extrinsic.

To avoid too much discontinuity from current practice, extrinsic functions should be defined as follows in order of preference:

(a) where possible, an XPath expression that can be used as the body of the function: for example local-name($node) is local-name-from-QName( node-name($node)).

👍

(b) if that's not possible or convenient, use an XQuery expression.

(c) if the equivalent is recursive or requires supporting functions, express the equivalence using XQuery function declarations. Unless we can come up with a more readable way of expressing recursive functions in XPath, we should avoid them.

Convenience is a rather subjective term.

We could have an introductory section which explains how XPath code is used in the Rules and which provides a simple example of recursion in XPath.

We can precede a recursive function definition with a suitable comment, such as:

(: Recursive function $factorial defined with the help of $factorial-inner :)

We shouldn't suppose that all implementors know XQuery well and any such assumption may really discriminate and be unfair to some potential implementors.

Some implementors may even have no XQuery processor available, not to speak about an XQuery 4.0 processor.

Not to speak any regular XSLT developer (user) who has no confidence in his XQuery knowledge and understanding and thus would feel inconvenient (hate) unfairly and unnecessarily taxed, and not confident reading the XQuery code.

They may also remain with the impression that the creators of the Spec were unfairly biased towards XQuery...

[ChristianGruen]

We shouldn't suppose that all implementors know XQuery well and any such assumption may really discriminate and be unfair to some potential implementors.

Until someone proves me wrong, I feel safe to say that everyone who’s smart enough to write an XPath 4.0 implementation will certainly be smart enough to understand some basic XQuery or XSLT code – let alone function declarations that basically have the same syntax as the function signatures in the XQFO spec.

No matter which language or pseudo-code we use, we should avoid syntactical constructs that don’t focus on the actual task, such as self-referencing function arguments. Just because something can be done doesn’t mean it should be done.

[dnovatchev]

Until someone proves me wrong, I feel safe to say that everyone who’s smart enough to write an XPath 4.0 implementation will certainly be smart enough to understand some basic XQuery or XSLT code – let alone function declarations that basically have the same syntax as the function signatures in the XQFO spec.

No matter which language or pseudo-code we use, we should avoid syntactical constructs that don’t focus on the actual task, such as self-referencing function arguments. Just because something can be done doesn’t mean it should be done.

Said the author of an XQuery processor ...

[ChristianGruen]

Said the author of an XQuery processor ...

…who included XSLT in the reply, and added a second comment on conciseness, which is more important than the used language.

The discussion is getting absurd. This is the current XQuery code for fn:flatten in the spec:

declare function flatten(
  $input as item()*
) as item()* {
  for $item in $input
  return if ($item instance of array(*)) then flatten(array:values($item)) else $item
};

An equivalent XPath version would be:

let $flatten-inner := function(
  $input as item()*,
  $self  as function(*)
) as item()* {
  for $item in $input
  return if ($item instance of array(*)) then $self(array:values($item), $self) else $item  
}
let $flatten := function(
  $input as item()*
) as item()* {
  $flatten-inner($input, $flatten-inner)
}
return ...

Only a minority of users would be able to judge that the second version is XPath at all.