This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Marked (probably) editorial. The definition of Core Functions is currently: "The core functions are: functions specified in [Functions and Operators 3.0] in either the standard function namespace or the namespace http://www.w3.org/2005/xpath-functions/math; plus functions defined in this specification in namespace http://www.w3.org/2005/xpath-functions/map." This should also include the constructor functions in the XSD namespace. (note that under xsl:evaluate we mention this omission, but elsewhere in the spec we do not, and I think we can assume that constructor functions are always in scope). In 9.7 Static Expressions, under Static Context Components for Static Expressions we use the phrase "The core functions defined in [Functions and Operators 3.0],". I propose to drop the "defined in [Functions and Operators 3.0]", as this would otherwise exclude the map functions (which are defined in 3.1).
Any change here would require very great care. As far as I can see the definition of "core function" is consistent with the way the term is used (15 usages, some hyperlinked and some not). Whether it's still a useful concept is another question. We might attempt a classification of functions as follows: (a) functions in the fn namespace defined in F+O 3.0, or 3.1 if appropriate (b) functions in the math namespace defined in F+O 3.0 or 3.1 (there are no substantive differences between 3.0 or 3.1) (c) functions in the map namespace defined in XSLT 3.0 or F+O 3.1 (there are no substantive differences between the two specifications) (d) functions in the array namespace defined in F+O 3.1 (e) constructor functions in the xs namespace for data types defined in XSD 1.0 or XSD 1.1 (f) functions in the fn namespace defined in XSLT 3.0 (g) user-written stylesheet functions (h) extension functions and then, by means of a table, indicate which of these categories are available (i) in ordinary XPath expressions (and patterns), (ii) in static expressions, and (iii) within dynamic XPath expressions (xsl:evaluate). But I don't think the spec is broken as it stands, and any work in this area needs care to make sure it doesn't break anything. Perhaps it's a candidate for a non-normative appendix.
I have attempted a summary categorization of available functions in Appendix G.1. Please review.
I'm not comfortable with this resolution. It doesn't really address the fact that the term "core function" is often used without much precision, and the fact that the definition is far from intuitive. I propose the definitions (in section 2.1, terminology): The term *core function* refers to a function that (a) is defined either in this specification, or in Functions and Operators (version 3.0 or 3.1 whichever is supported by the processor), and (b) is in one of the namespaces conventionally referred to be the prefixes fn, math, map, or array. and add the Note: the term *core function* therefore excludes user-defined functions, constructor functions, and extension functions. The term *core XPath function* refers to a *core function* that is defined in Functions and Operators (version 3.0 or 3.1 whichever is supported by the processor). with the note: In other words, the term "core XPath function" generally excludes functions defined in this specification, except in the case of functions such as json-to-xml that are replicated in this specification and in Functions and Operators 3.1; these functions are included in the definition provided that the processor supports XPath 3.1. Then replace/revise the usage of the term "core functions" as follows: 5.3.1, statically known function signatures: replace the first two bullets by "The core functions" (hyperlinked) and delete the note saying "It follows from the above that a conformant XSLT processor must implement the entire library of core functions." 9.7 Static Expressions, statically known function signatures, replace "The core functions defined in [Functions and Operators 3.0]," by "The core XPath functions" (hyperlinked). 10.4.1, function signatures (change to "statically known function signatures"): Change "All core functions" to "All core XPath functions" (hyperlinked). The context makes it clear that this intends to exclude XSLT-defined functions. 20, change the first sentence to "This section describes XSLT-specific additions to the core XPath function library." Drop the new appendix G.1 (I think that it's difficult to make it both simple and correct at the same time; we can't afford for it to be simple and wrong, and if it is complex then it serves no useful purpose because it replicates information elsewhere in the spec.
(In reply to Michael Kay from comment #3) > and add the Note: the term *core function* therefore excludes user-defined > functions, constructor functions, and extension functions. Why are we excluding constructor functions? I thought at some point we agreed it was an unnecessary restriction. It is rather odd that I can create a static variable like this: <xsl:variable static="true" select="1" as="xs:int" name="x" /> But that I cannot do this: <xsl:variable static="true" select="xs:int(1)" as="xs:int" name="x" />
I had an action to review this. I have decided to avoid using the term "core functions" * Where the term is used casually, I have found a more helpful phrase (sometimes just "function") * Where the precise meaning of the term is important, I have in effect expanded the definition in situ.
The WG accepted the resolution