Re: Function naming: Problems and proposed solution

A couple of observations.

On Sat, 28 Nov 2020 at 11:16, Michael Kay <mike@saxonica.com> wrote:


> At present I'm not sure that this gives much benefit over using multiple
> namespaces, and it's a bit hard to see how to introduce it alongside
> existing mechanism without ending up with a rather clumsy mixture of
> different approaches coexisting.
>

Suggestion: 'semi' fixed ns prefixes. maths is an obvious one.
How and where I'll leave to others.



>
> I've been trying to find a way that still uses namespaces, but makes them
> more flexible. For example, by separating the namespace context for
> functions from that for elements, and/or making the binding of prefixes to
> namespaces more adaptable - for example by allowing functions from multiple
> namespaces to be used without a prefix provided the reference is
> unambiguous.
>

I think I (and others) might find this even more confusing.



> I've also wondered about attaching special meaning to "." in a function
> name, so for example you can refer to the math functions as math.sin(x)
> without needing to bind a namespace prefix, and with some kind of mechanism
> for dropping the "math" prefix if it's not needed for disambiguation.
>


Apart from dropping the prefix I like this notation.
Hence math.sin() would be (to me) clear without a ns definition

"implementation dependent" ns -> prefix is an obvious one,
though I wouldn't like it.
  How feasible is it to get (at least some) prefixes agreed
with implementers, if not in the rec?

regards




-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.