[FO] Conversion between xs:QName and Q{uri}local format

[michaelhkay]

It would be good to have functions to convert from Q{uri}local format to xs:QName (perhaps with the option of supplying a prefix), and the reverse, generating Q{uri}local from an xs:QName.

I don't think we can extend the xs:QName constructor function to do this, because that has to remain consistent with XSD and (sadly) we can't change the lexical space in XSD.

So I would suggest a single-argument form of fn:QName that accepts either local or Q{}local or Q{uri}local. But this doesn't allow a prefix to be added. An alternative would be fn:EQName#1 accepting local or Q{}local or Q{uri}local, with an optional second argument to supply a prefix.

For the reverse, perhaps fn:EQName-from-QName#1? But the terminology here is a bit loose: in the grammar, EQName covers various formats of which URIQualifiedName is one. But fn:URIQualifiedName-from-QName is a bit of a mouthful.

[ChristianGruen]

My favorite would be fn:QName. As the function returns an xs:QName value, fn:EQName might imply there’s something like xs:EQName. Next, non-experts might be confused what an EQName actually is (and I agree it seems not to be clearly defined). Developers are already confused why there are QNames and NCNames and not just names.

For similar reasons, I would propose not to include a dedicated function to create string representations of QNames. If it is really required, it can easily be constructed with string concatenation or by calling fn:serialize:

serialize(
  <x xmlns='x'/>/node-name(),
  map { 'method': 'adaptive' }
)

[dnovatchev]

I will welcome any function that will allow me to use in my XPath code a prefix and not the monstrous Q{http://www.fxpath.org}loadFunctionLibraries#1(args, here).

But isn't it simpler and much better to introduce a few fixed prefixes, following the good example of XQuery?

I have always envied XQuery for having a fixed "xs:" prefix, which I had to define literally thousands of times in XSLT, and as we see above, having to use the Q{uri}local is even much worse in pure XPath.

Also, having different set of predefined namespace prefixes in XQuery, XSLT and XPath makes it rather error-prone to copy-paste code from/to code written in each of this languages.

[michaelhkay]

One thing I've done in my proposals is to decouple the default element namespace from the default type namespace. This makes it possible to use unprefixed names for types, for example as="integer" rather than as="xs:integer" (except in the case where you stylesheet is schema-aware and you need to refer to non-namespace types; but even in that case, you can refer to them as Q{}local. The other thing I've done for XSLT is to define an <xsl:function-library> element that decouples the namespaces used for resolving function names from the XML namespace declarations appearing in the stylesheet. This avoids the namespace declarations finding their way into the result tree, and into the run-time environment. For XPath I'm currrently proposing with xmlns="http://namespace-1/" xmlns:map="http://www.w3.org/2005/xpath-functions/map { 2+2 + map:size(map{}) } But if we're prepared to be radical (and upset some people) I think we can do better. Personally I'd like to get rid of this "http://www" nonsense altogether, in favour of dot-separated hierarchic names as used in Java and C#. Our core functions would then have "long names" like xpath.remove() and xpath.math.sin(), and short names like remove() and sin(). If you import a qualifier like xpath.math, then you can refer to its functions by short name provided the short name is unambiguous; to disambiguate it, you add the qualifier. For compatibiliity, a function can also have a QName. But this doesn't solve the whole problem; you can still only have one "remove()" function that can be used without qualification. To solve that one, we need to pursue the other avenue of making the resolution type-sensitive. Michael Kay Saxonica

…

On 28 Nov 2020, at 21:18, dnovatchev ***@***.***> wrote: I will welcome any function that will allow me to use in my XPath code a prefix and not the monstrous Q{http://www.fxpath.org}loadFunctionLibraries#1(args, here). But isn't it simpler and much better to introduce a few fixed prefixes, following the good example of XQuery? I have always envied XQuery for having a fixed "xs:" prefix, which I had to define literally thousands of times in XSLT, and as we see above, having to use the Q{uri}local is even much worse in pure XPath. Also, having different set of predefined namespace prefixes in XQuery, XSLT and XPath makes it rather error-prone to copy-paste code from/to code written in each of this languages. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASIQIUMV4V3GRMVIYBVRTTSSFSI5ANCNFSM4UFNCR6A>.

[dnovatchev]

Our core functions would then have "long names" like xpath.remove() and xpath.math.sin(), and short names like remove() and sin(). If you import a qualifier like xpath.math, then you can refer to its functions by short name provided the short name is unambiguous; to disambiguate it, you add the qualifier

This would be great!

Also, something very useful is aliasing of namespace-chain (like the using directive in C#), so instead of having to type:

xpath.math.trigonometry.sin()

One has:

let $trig := namespace-path-shortcut(xpath.math.trigonometry)
  return
      trig.sin(trig.Pi() / 2)

Not amazingly, name1.name2. ... nameN can be the same as $name1?$name2?...?NameN :)

In the latter case not only we have some abstract notion about what each string-chain means, but because these are maps, we can actually interrogate them, and do other useful things with them.

Thanks,
Dimitre

[michaelhkay]

A specific proposal.

(1) A new function expanded-QName(xs:QName) => xs:string

The function returns a string in the format Q{uri}local, where the uri is zero-length if the name is in no namespace. The prefix is dropped.

(2) An enhancement to the semantics of fn:QName. I propose a departure from our normal practice such that the arity-1 and arity-2 versions of the function behave differently.

The arity-2 version corresponds to the 3.1 specification.

The new arity-1 version takes a single argument eqname as xs:string, where the value follows the syntax of the XPath EQName production. If the value consists of a local name only, it is treated as a no-namespace name. If it is in the form prefix:local, then the function behaves like xs:QName (using prefix bindings from the static context). If it is in the form Q{uri}local, then the result is a QName with the relevant URI and local part, with no prefix component.

[ndw]

👍

[ChristianGruen]

Merged (#207).