Structural proposal (ThinLayer:tm:) : Add a layer of thin spec between XPath and the XPath Derived Language

[innovimax]

XPath is ubiquitous and is used even in places where we have no idea On the other hand XPath is very useful to us as the centerpiece of XSLT, XQuery

In order to allow people to have a more expanded use of XPath without to have to get the whole XSLT, XQuery story, it is perhaps the time to consider adding a thin layer of spec in order to have

1. XPath
2. Some typing definition mechanism
3. Some function definition mechanism

The idea is also to better integrate this with all Validation technologies (XSD, Relax NG, NVDL, JSONSchema, etc.) and allow EXPath, EXQuery and other to have a standard way to use all this around

We also want people that want to use only XPath (for example in LinQ or inside SQL) to have a broader capacity to interact with XML (instead of being limited to XPath 1.0 with namespaces)

I will try to add more and more precision to this proposal along the line, but I feel it is good enough to be a first stone to break and allow people to help drive this initiative

For the moment the name of this new beast is XPathWithCustomizableTypesAndFunctions in our proposal call XPath Next https://github.com/XPath-Next/XPath-Next/blob/first-draft/spec.md

[michaelhkay]

I find it a little bit difficult to see where you draw a line between this and XQuery. It's hard enough to decide what goes in XPath and what goes in XQuery already, without more gradations in between. What properties do you want this language to have that XQuery doesn't have?

[dnovatchev]

What properties do you want this language to have that XQuery doesn't have?

I don't think @innovimax wants the proposed language to still be a proper subset of XQuery and to be used in XSLT at any place where an XPath expression is expected.

@innovimax Please, correct me if I have misunderstood.

---

OK, I read the spec.md and it seems that this is more ambitious than it seemed.

I personally would prefer to have just Levels 0 to 3, with level 2 (EXPath) not included. This can be implemented fully based on F&O 3.1 and higher.

And whatever we find at Level 3 would be a candidate to be included in the next version of FO or as a new XPath feature.

[innovimax]

Let me start by what it isn't then @michaelhkay It clearly is NOT doing

• any node construction (only selection of existing nodes, map and arrays that are around)
• any serialization (that is left the host languages)

On the other hand, windowing for example could be part of that layer since it would be useful everywhere XPath is used

I hope this makes it clearer

[innovimax]

@dnovatchev XPath Next is the whole architecture, hence the various levels of integration

XPathWithCustomizableTypesAndFunctions should indeed cover level 0, 1 and allow level 2 and should become the general XPath pluggable module to use XPath as a selection language

[michaelhkay]

Well, I've been finding a strong need to add node construction to XPath...

On the other hand I see no need for full FLWOR expressions in XPath.

Perhaps we need some new modularisation of the XQuery spec? What I don't see is any need to replace things that exist in XQuery with something that's functionally equivalent but syntactically different.

[innovimax]

@michaelhkay I think we completely agree on the last (the syntax should stay consistent to the cross language users) and perhaps indeed there should be Instead of

$$ XPath \subset XQuery ; XPath \in XSLT $$

something more like

$$ XPath \subset ThinLayer ; ThinLayer \subset XQuery ; ThinLayer \in XSLT $$

Where this ThinLayer:tm: is a bigger superset of XPath and a smaller subset of XQuery

Once this layer set, we could discuss creating another layer, let's call it ThickLayer:tm: and it may include node creation for example

[AlainCouthures]

Hello,

 

XForms is another host language for XPath.

 

XForms 2.0 Specifications are currently adding functions for node creation instead of accepting XQuery instructions. They also define their own syntax for declaring global functions.

 

It does not sound convenient for authors, who might know XQuery already, to have two syntaxes for the same purpose.

 

The XQuery prolog is a list of declarations, some with expressions, separated by ; whereas the XQuery body is a single expression. XForms would benefit for the use of XQuery body and not just XPath.

 

There is also an XML syntax for XForms actions which could be replaced by scripts written with XQuery Update Facility for node updates. Serialization can already be done with the fn:serialize#2 function.

 

What do you think?

 

--Alain

 

Le 05/04/2023 11:14 CEST, Innovimax ***@***.***> a écrit :

 

 

  @michaelhkay I think we completely agree on the last (the syntax should stay consistent to the cross language users) and perhaps indeed there should beInstead of $$ XPath \subset XQuery ; XPath \in XSLT $$ something more like $$ XPath \subset ThinLayer ; ThinLayer \subset XQuery ; ThinLayer \in XSLT $$ Where this ThinLayer™️ is a bigger superset of XPath and a smaller subset of XQuery Once this layer set, we could discuss creating another layer, let's call it ThickLayer™️ and it may include node creation for example —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[dnovatchev]

It clearly is NOT doing

• any node construction (only selection of existing nodes, map and arrays that are around)
• any serialization (that is left the host languages)

@innovimax But node construction has been in the standard XPath for more than 10 yeas, thus it is even available at Level 0:

fn:parse-xml

The same goes for serialization:

fn:serialize

[dnovatchev]

Perhaps we need some new modularisation of the XQuery spec? What I don't see is any need to replace things that exist in XQuery with something that's functionally equivalent but syntactically different.

Some people, myself included don't really care what will be added to XQuery. When an overly verbose language is made even more verbose this just adds more reasons not to use it.

And XPath is slimmer, really beautiful and its utility is that it is a single language available to XQuery (as a subset), in XSLT (as an expression language), and in any other environments that need it.

Thus: Add/modify/delete features in a single place and you avoid the need to do this in N different languages. No redundancy!

As we see, there is a substantial user group that needs just XPath and nothing else, and this proposal has been raised by a person representing this user group,

And we have to honor diversity!

I personally am more conservative than @innovimax and think that having just his levels 0, 1 and 3 (note Level 2 EXPath is excluded) is what XPath needs and what it essentially is even today. Given the functions fn:transform and fn:load-xquery-module, one can use in XPath almost any feature of XSLT and XQuery.

Also, frequently calling these functions to access particular type of functionality will be a strong indicator what needs to be added to the language next.

[michaelhkay]

I agree with you entirely that the beauty of XPath is in large degree due to its smallness, which is only possible because of its architectural relationship to the host languages responsible for setting the static context for XPath execution.

And that is precisely the reason why I think we should avoid extending the architectural scope of what XPath attempts to do. XSLT and XQuery have declaration constructs for defining the static context for evaluation of XPath expressions; XPath itself has no such constructs, it depends on a host language for that capability. I think that's the way it should remain.

[AlainCouthures]

XPath is surely beautiful as long as there is no need for multiple lines to write an expression.

 

The simpleMap operator is more concise than FLWOR instructions which could have been XQuery-only.

 

Node constructors would be useful indeed even for XPath for XForms and local functions help to reduce expression lengths.

Le 05/04/2023 17:54 CEST, Michael Kay ***@***.***> a écrit :

 

 

  I agree with you entirely that the beauty of XPath is in large degree due to its smallness, which is only possible because of its architectural relationship to the host languages responsible for setting the static context for XPath execution. And that is precisely the reason why I think we should avoid extending the architectural scope of what XPath attempts to do. XSLT and XQuery have declaration constructs for defining the static context for evaluation of XPath expressions; XPath itself has no such constructs, it depends on a host language for that capability. I think that's the way it should remain. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[michaelhkay]

Alain, can you point me to what XForms is doing in the area of node construction?

[AlainCouthures]

https://www.w3.org/community/xformsusers/wiki/XPath_Expressions_Module#Node_Creation_Functions

Le 05/04/2023 19:26 CEST, Michael Kay ***@***.***> a écrit :

 

 

  Alain, can you point me to what XForms is doing in the area of node construction? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[innovimax]

It's interesting that indeed most of the extension of XPath are done at the function (F&O style) stage and not at the language stage which once again goes make this this ThinLayer:tm: a potential candidate for most of the fancy extension even for node creation (as XForms just did)

However, I think we should be careful of not creating problems with typing

[dnovatchev]

I agree with you entirely that the beauty of XPath is in large degree due to its smallness, which is only possible because of its architectural relationship to the host languages responsible for setting the static context for XPath execution.

And that is precisely the reason why I think we should avoid extending the architectural scope of what XPath attempts to do. XSLT and XQuery have declaration constructs for defining the static context for evaluation of XPath expressions; XPath itself has no such constructs, it depends on a host language for that capability. I think that's the way it should remain.

As type specification is already part of XPath 3.1, the most appropriate place to give these types a name is again in XPath.

In the discussion of the proposal for typenames I pointed out that artificially pulling these out of XPath and thus having to introduce them (at least) in two languages (XQuery, XSLT, ...) creates a redundancy when using the so defined types, requiring 2 or more (not a single one, atomic) definitions and 2 or more (not a single one, atomic) modifications. This is no longer just about user convenience and preferences/taste, but goes much deeper affecting consistency and safety. Any period of inconsistency (during which all necessary type updates have not been completed in all code bases depending on these types) is affecting the correctness of the user-written functionality.

We have the responsibility never to allow such issues if we can eliminate them by design!!!

[dnovatchev]

XSLT and XQuery have declaration constructs for defining the static context for evaluation of XPath expressions; XPath itself has no such constructs, it depends on a host language for that capability. I think that's the way it should remain.

This isn't true.

There are standard XPath functions, like fn:doc, and others that are being used to set the context while evaluating an XPath expression.

An XPath program (expression, strictly speaking but I deliberately use "program" here) can set its own context once after the XPath engine has been invoked for its evaluation.

An XPath program doesn't need to be started within XQuery or XSLT, it can be run totally independently of these, so called "host languages".

An XPath program can load dynamically all XPath function libraries it needs by simply calling a standard F&O function, such as fn:load-xquery-module.

Having dynamically loaded all XPath function libraries that it needs, the XPath program then executes and performs all the intended, expected. useful functionality it was written for. No XSLT, XQuery or any other intermediaries!

As simple as in this example:

let  $opts := map{"location-hints": 'file:///C:/git/FunXPath/tests/BaseX/SimpleLibrary.xpath'} ,
     $m := load-xquery-module('F', $opts)
   return ($m?variables?*?incr(3), $m?variables?*?idiv(9,4))

The above code doesn't need to be evaluated within any XSLT or XQuery code, and it is useful by itself / standalone:

[michaelhkay]

We're talking here about binding of names to things. In XPath we can currently use names that refer to variables, functions, resources on the web, namespaces, decimal formats, collations, and schema types. In all these cases the binding of names to things is established in the static context (the only exception is that we can declare local variable names). XQuery and XSLT have mechanisms for populating the static context, XPath does not. That in my view is a defining characteristic of XPath. And I think it's done that way for a good reason. XPath is designed so that you can invoke/evaluate expressions from some host language, and generally you're going to invoke lots of expressions independently, generally all of them sharing the same or a similar static context. So you want to establish something in the static context once, so that you can reference it repeatedly.

You write "There are standard XPath functions, like [fn:doc], and others that are being used to set the context while evaluating an XPath expression." That's not true. fn:doc() does not change the context. There are operators like "/" that set the dynamic context for their operands, but (with the exception of local variable bindings) there's nothing that changes the static context. Even load-query-module() doesn't change the context - it gets some resources from the external environment, but it doesn't change the environment.

We could add new mechanisms for initialising the static context for XPath, but it would change the architecture and role of the language, and would remove any useful distinctions between the role of XPath and XQuery.

Types are used mainly in variable and function declarations: the reason you want to give a name to a type such as record(ssn, age, date-of-birth, salary, home-address, phone-number) is that you want to use this type repeatedly, and most of the time, you're going to be using it in function signatures. You want the type to have global scope, which means the binding has to have wider scope than a single XPath expression.

You say: "As type specification is already part of XPath 3.1, the most appropriate place to give these types a name is again in XPath." But XPath 3.1 cannot define new types, it can only construct references to types that already exist: either types like record(double, double) that are composed from primitives in the language, or types like element(*, part-number) that are composed from types defined in an imported schema (which is placed in the static context using a mechanism over which XPath has no control). If you gave a type a name in XPath, what would be the scope of that name? How would you use the name in a different XPath expression?

You are right of course that it is possible to write non-trivial programs in XPath without having anything useful in the static context. But that's not how the language is designed to be used, it's not how most people use it, and I don't think it's a mode of use that we should optimise for.

[dnovatchev]

If you gave a type a name in XPath, what would be the scope of that name? How would you use the name in a different XPath expression?

The containers of useful type-names are the XPath function libraries and these (XPath function libraries) are universally accessed at present via standard F&O functions as shown previously, in all independently existing XPath expressions (programs!) that need these.

So, it is natural for an XPath function library to not only provide commonly-needed functions, but also type-names to refer to specific signature parts of these.

[dnovatchev]

But XPath 3.1 cannot define new types, it can only construct references to types that already exist: either types like record(double, double) that are composed from primitives in the language, or types like element(*, part-number) that are composed from types defined in an imported schema (which is placed in the static context using a mechanism over which XPath has no control).

The proposal for type-names is just that: giving names to existing types. It doesn't treat the topic of constructing new types out of thin air.

As articulated in the preceding comments, a self-contained XPath program benefits from the convenience of referring to types by name. Type-name definitions will be provided to all independent XPath programs that import their containers (XPath function libraries).

This also avoids the need to define more than once the same type-name that is needed both in XSLT and XQuery code, completely eliminating the possibility for redundancy and inconsistencies.

[michaelhkay]

What exactly do you mean by the term "XPath function library"? We can specify a function library (in a specification document), or we can implement a function library in XQuery or XSLT, but we can't currently implement a function library (such as the EXPath binary function library) in XPath.

And what do you mean by "independent XPath programs that import their containers"? You're using language and concepts here that aren't in the XPath specification.

[dnovatchev]

You are right of course that it is possible to write non-trivial programs in XPath without having anything useful in the static context. But that's not how the language is designed to be used, it's not how most people use it, and I don't think it's a mode of use that we should optimise for.

Yes, it was designed for use by white males only 😅

Do we need the equivalent of "_The Voting Rights Act of 1965_", signed into law by President Lyndon B. Johnson, aimed to overcome legal barriers at the state and local levels that prevented African Americans from exercising their right to vote as guaranteed under the 15th Amendment to the U.S. Constitution?

[ChristianGruen]

Yes, it was designed for use by white males only 😅

Sounds like cultural appropriation. Shouldn't we rather ask non-white non-males about your proposal? ;)

[dnovatchev]

What exactly do you mean by the term "XPath function library"? We can specify a function library (in a specification document), or we can implement a function library in XQuery or XSLT, but we can't currently implement a function library (such as the EXPath binary function library) in XPath.

I gave a complete example in this (preceding) comment above.

In this specific example the XPath function library is contained in 'file:///C:/git/FunXPath/tests/BaseX/SimpleLibrary.xpath'

Its contents happens to be this (pure XPath expression, embraced by XQuery blah-blah-blah, so that it is loaded without problem by the standard system function fn:load-xquery-module:

module namespace f = "F";
declare variable $f:Math :=
      map {
            'incr': function($n as xs:integer) {$n +1},
            'mult': function($m as xs:integer, $n as xs:integer)  {$m * $n},
            'decr': function($n as xs:integer) {$n -1},
            'idiv': function($m as xs:integer, $n as xs:integer) {$m idiv $n}
          };

And again, here is the result of this, executed in the Oxygen XPath Builder:

And what do you mean by "independent XPath programs that import their containers"? You're using language and concepts here that aren't in the XPath specification.

Again in the preceding comments I emphasized that I am using deliberately the term XPath program as a synonym of XPath expression, which is the center-piece of the XPath specification.

[michaelhkay]

module namespace f = "F";
declare variable $f:Math :=
      map {
            'incr': function($n as xs:integer) {$n +1},
            'mult': function($m as xs:integer, $n as xs:integer)  {$m * $n},
            'decr': function($n as xs:integer) {$n -1},
            'idiv': function($m as xs:integer, $n as xs:integer) {$m idiv $n}
          };

Why do you prefer to write it this way rather than:

module namespace f = "F";
declare function f:incr ($n as xs:integer) {$n +1};
declare function f:mult ($m as xs:integer, $n as xs:integer)  {$m * $n};
declare function f:decr ($n as xs:integer) {$n -1};
declare function f:idiv ($m as xs:integer, $n as xs:integer) {$m idiv $n};

The second form has the clear advantage that the functions can easily invoke one another. What disadvantages does it have?

[dnovatchev]

module namespace f = "F";
declare variable $f:Math :=
      map {
            'incr': function($n as xs:integer) {$n +1},
            'mult': function($m as xs:integer, $n as xs:integer)  {$m * $n},
            'decr': function($n as xs:integer) {$n -1},
            'idiv': function($m as xs:integer, $n as xs:integer) {$m idiv $n}
          };

Why do you prefer to write it this way rather than:

module namespace f = "F";
declare function f:incr ($n as xs:integer) {$n +1};
declare function f:mult ($m as xs:integer, $n as xs:integer)  {$m * $n};
declare function f:decr ($n as xs:integer) {$n -1};
declare function f:idiv ($m as xs:integer, $n as xs:integer) {$m idiv $n};

The second form has the clear advantage that the functions can easily invoke one another. What disadvantages does it have?

The first is pure XPath, sandwiched by some "XQuery packet", while the second is XQuery.

In an XPath function library we use pure XPath. The packaging is like the infrastructure when splitting a message into packets to send over the network -- the real contents is not aware of this packaging.

If we want one of the functions to call another from this XPath function library, we could always pass any such functions that it needs as parameters, or even better, the whole Function Library (the map) as a single parameter, the same way we can pass it to itself so that it can call itself recursively. Alternatively, any such function can on its own "import" any needed XPath Function library, when used independently.

[Arithmeticus]

Doesn't "XQuery packet sandwich" contradict "pure XPath"? One could build an analogous argument around an XSLT file as a "packet" for an XPath function library (delivered via transform()). I don't think that entails calling it pure XPath. Doing so gives me a nagging suspicion that the end game is to expand XPath enough that host languages are no longer necessary. If that's not the case, clarification would be welcome.

The introduction of the XPath 4.0 specs has prose declaring the intended purpose of the language. Clearly, parts of XPath are no longer confined to that original vision: "to address the nodes of XML trees and JSON trees". But there is not a clear indication of XPath's limits.

Might I propose that a useful way to make progress on this discussion would be for someone to draft a succinct paragraph or two. The prose would present the principles that guide the limits to XPath and explain the benefits gained in adhering to those limits. That draft statement could be put either in 1. Introduction or as a new section 2.1 Scope (under Basics, before Terminology). At that point we'll have a position we can discuss, debate, and refine. Consensus on that point would clarify whether some open issues are in-scope or not, and help the working group dispense with them more efficiently.

[dnovatchev]

Doesn't "XQuery packet sandwich" contradict "pure XPath"?

Absolutely no.

As I said: "The packaging is like the infrastructure when splitting a message into packets to send over the network -- the real contents is not aware of this packaging."

The same way as the text of an Html page you have created doesn't know that on sending the response to the client it has been probably split into many packets (sandwiched between some protocol headers and footers) that are potentially sent in parallel asynchronously via different routes over the network, and then, at the receiving end, assembled from all of the received packets after ordering them and stripping off the low-level packaging.

What is "imported" into the XPath expression, needing access to the XPath Function Library, is just a map (assume in a variable named $myFuns), whose keys are the names of the functions in this library, and where the corresponding value for a key "Xyz" is $myFuns?Xyz - that is the inline (dynamic) XPath function that we know under the name "Xyz".

Then we can simply invoke this function (assuming in this example that it takes a single argument) as $myFuns?Xyz($myArg1)

---

This is not a new concept. I presented this concept almost 10 years ago at Balisage 2013. The paper is here:

https://www.balisage.net/Proceedings/vol10/html/Novatchev01/BalisageVol10-Novatchev01.html

and the slides and code are here:

https://www.balisage.net/Proceedings/vol10/author-pkg/Novatchev01/BalisageVol10-Novatchev01.html

At that time XPath 3.1 wasn't yet produced and (I think) we didn't have such standard XPath functions as fn:load-xquery-module and fn:transform but even then there were ways to import an XPath function library.

[innovimax]

Interesting, @dnovatchev you're using maps as namespace

$myfunctions?blah instead of

myfunctions:blah

but @michaelhkay mentionned, this will be difficult to reuse by other functions

I see how the trick with maps is helping without any change in the current spec, but it also makes reuse unnecessarily complicated

[dnovatchev]

Interesting, @dnovatchev you're using maps as namespace

$myfunctions?blah instead of

myfunctions:blah

but @michaelhkay mentionned, this will be difficult to reuse by other functions

I see how the trick with maps is helping without any change in the current spec, but it also makes reuse unnecessarily complicated

@innovimax,

Actually this doesn't affect reusability at all.

Any function within a function library has access to any needed function in any needed function library and these are completely independent.

Please, see my answer to @michaelhkay :

If we want one of the functions to call another from this XPath function library, we could always pass any such functions that it needs as parameters, or even better, the whole Function Library (the map) as a single parameter, the same way we can pass it (the function) to itself so that it can call itself recursively. Alternatively, any such function can on its own "import" any needed XPath Function library and call any necessary functions from this function library.

[innovimax]

`module namespace f = "F";

declare variable $f:Math := map { 'is-odd': function($n as xs:integer) {$n mod 2 = 1}, 'is-even': function($n as xs:integer) {not (is-odd($n))}, }; `

@dnovatchev how do I reference is-odd from inside is-even ?

[dnovatchev]

`module namespace f = "F";

declare variable $f:Math := map { 'is-odd': function($n as xs:integer) {$n mod 2 = 1}, 'is-even': function($n as xs:integer) {not (is-odd($n))}, }; `

@dnovatchev how do I reference is-odd from inside is-even ?

@innovimax:

There are at least two ways to do this, I would recommend this one:

module namespace f = "F";

declare variable $f:Math :=
map {
'is-odd': function($n as xs:integer) {$n mod 2 = 1},
'is-even': function($n as xs:integer) 
  {
     let  $opts := map{"location-hints": 'Some-Specific-URI'} ,
           $m := load-xquery-module('F', $opts)
      return 
           not($m?variables?*?is-odd($n))
    },
};

In an ideal world our "import-function" (load-xquery-module) would have a parameter to cache its results, so any subsequent import of the same XPath Function Library would come for free.

There has also been an attempt (proposal) by @michaelhkay to somehow implement navigation up in a nested-maps-tree, and if this is successfully designed and implemented in XPath 4, then one will simply climb-up one level and then get whatever sibling function they need.

This could also be done using my CompXPath proposal, using the preceding-sibling-member:: and the following-sibling-member:: axes, and is a good use-case for introducing just a general sibling-member:: axis.

Even with these still being at the early-proposals stage, the solution I provided above works immediately (now) at present.

Another good way is to pass the map as a parameter to its children functions. This is how instance-level methods are usually implemented in PLs, they have a (hidden) parameter which is the this object.

I have been successfully doing this for more than 10 years, and people were initially quite surprised to learn about Recursion with anonymous functions.

Read more about this here. 😄

Do note that having a this parameter and importing in the same function whichever other XPath Function Library we need, these two approaches are complementing each other and can be used together. They are not mutually exclusive.

Finally: The obvious way for functions that are values of the same map to reference themselves, and which I have used as author of XPath Function Libraries, is simply to refer to the internal variables defining these functions - not to the map member.

Here is a quick example how this is done in the Xpath Function Library special-folds.xpath just the beginning of the library below:

module namespace f = "F";
declare variable $f:specialFolds :=  

  (
let $vBaseFXpathUri := (environment-variable('FXpathDir')[normalize-space()], '..')[1],

(: =============== Include operators.xpath ============================:)
    $optsOps  := map{"location-hints": $vBaseFXpathUri  || '/fModules/operators.xpath'} ,
    $ops := load-xquery-module('F',$optsOps)?variables?*,

(: ================ Include folds.xpath ===============================:)
    $optsFolds := map{"location-hint": $vBaseFXpathUri  || '/fModules/folds.xpath'} ,
    $folds := load-xquery-module('F',$optsFolds)?variables?*,

 (:    Special Folds
   ====================================================================:)
   $and := function ($booleans as xs:boolean*) as xs:boolean
{
  $folds?foldl_($ops?conjunction, true(), $booleans)
}, 

   $or := function ($booleans as xs:boolean*) as xs:boolean
{
  $folds?foldl_($ops?disjunction, false(), $booleans)
},

   $any := function($f as function(item()) as xs:boolean, $list as item()* ) as xs:boolean
{
  $or($list!$f(.))
},   

   $all := function($f as function(item()) as xs:boolean, $list as item()* ) as xs:boolean
{
  $and($list!$f(.))
},

.   .    .    .    .    .    .

Do note how $any uses $or (an internal variable whose value is a function defined in the same library), and $all uses $and (again defined in the same library). 😃

Also this is a good demonstration how a function library imports and uses any other function libraries, in this case folds.xpath and operators.xpath.

[rhdunn]

@dnovatchev While being able to define functions in XPath as a scoped module by making use of maps is interesting, not everyone wants to/writes functions in that way. Some people write in XQuery, others in XSLT. Having the ability to support a concept (named types, functions, global variables, etc.) in all 3 cases is useful even if you don't specifically have a need for it -- that is, not everyone writes things in pure XPath.

Note: I'm not opposed to having a mechanism to provide a locally scoped name for a type, like you can define local variables (and in the case of the draft with expression have locally defined/scoped namespaces), but that shouldn't prevent them being globally defined within the XQuery and XSLT static context defining mechanisms.

The way I see it is that XQuery and XSLT (and to some extent JSONiq) are all different syntaxes on a shared data and processing model. There are some things that XQuery does that XSLT does not, and vice-versa. I would like to see the two become closer where possible.

[dnovatchev]

@dnovatchev While being able to define functions in XPath as a scoped module by making use of maps is interesting, not everyone wants to/writes functions in that way. Some people write in XQuery, others in XSLT. Having the ability to support a concept (named types, functions, global variables, etc.) in all 3 cases is useful even if you don't specifically have a need for it -- that is, not everyone writes things in pure XPath.

Exactly, @rhdunn , and this is exactly where choosing XPath shines!

An XPath feature is also an XQuery feature, because XPath ⊂ XQuery.

In XSLT we can have anything that is created in a given XPath expression simply by having:

<xsl:variable name="myXxxTypeNames" select="{XPath exapression defining some type-names}"/>

You want this at the global XSLT scope? Then simply declare this variable at the global level.

Note: I'm not opposed to having a mechanism to provide a locally scoped name for a type, like you can define local variables (and in the case of the draft with expression have locally defined/scoped namespaces), but that shouldn't prevent them being globally defined within the XQuery and XSLT static context defining mechanisms.

Yes, just use the necessary XPath expression anywhere you need it 😄

The way I see it is that XQuery and XSLT (and to some extent JSONiq) are all different syntaxes on a shared data and processing model. There are some things that XQuery does that XSLT does not, and vice-versa. I would like to see the two become closer where possible.

Exactly! The obvious way to share capabilities is have them in XPath!

[michaelhkay]

There's been a healthy discussion here but there is no concrete issue on the table and no concrete proposal to fix it. Until that is put on the table, I don't think there is any purpose served in keeping the issue open, so I am marking it as a candidate for closing with no action. Any concrete proposal to change our specifications is probably best handled as a separate issue.

[ndw]

At meeting 039 the CG agreed to close this issue without further action.