Establish a default value for the XSLT fixed-namespaces attribute

[dnovatchev]

Establish a default value for the XSLT fixed-namespaces attribute

[liamquin]

I don't think we need to compare fixed-namespaces to World War Two.
fixed-namspaces="#standard thisfile.xsl" might be interesting, and it'd be nice if we could use #current or something to do that. That way you get map, array, err, xs, for free, but can also use others.

[michaelhkay]

It's not an accidental omission! The reason there is no default is for backwards compatibility.

[dnovatchev]

It's not an accidental omission! The reason there is no default is for backwards compatibility.

Why do you think backwards compatibility would be affected?

Can you provide any example where a currently working XSLT version 3, 2 or 1 transformation would change its behavior and either end up in error or in producing a different result?

[michaelhkay]

If you set fixed-namespaces="#standard" in the xsl:stylesheet element, then <xsl:function name="my:function"> is going to give a static error saying the prefix "my" isn't declared. You need to move the declaration of prefix my into the fixed-namespaces attribute.

[dnovatchev]

If you set fixed-namespaces="#standard" in the xsl:stylesheet element, then <xsl:function name="my:function"> is going to give a static error saying the prefix "my" isn't declared. You need to move the declaration of prefix my into the fixed-namespaces attribute.

In a legacy (<= ver 3.0) XSLT transformation, if it was compiling at all, the prefix "my" would have been already declared, so what is described above cannot happen.

[michaelhkay]

No, the point about fixed-namespaces is that the namespace bindings are fixed for the stylesheet module; if you use it, ordinary XML namespace declarations are ignored.

That's because a strong part of the motivation for the feature was that the whole stylesheet module should use a consistent set of namespace bindings, which aren't retained at run-time, to eliminate a significant performance penalty when each expression potentially has different in-scope namespaces.

[dnovatchev]

No, the point about fixed-namespaces is that the namespace bindings are fixed for the stylesheet module; if you use it, ordinary XML namespace declarations are ignored.

Wow... Then this whole concept of "fixed-namespaces" is not useful. I thought that the fixed namespace prefixes bindings are in addition to all other namespace declarations in the stylesheet. Then this would be useful.

If I knew that this was an "all or nothing" replacement of namespace declarations, then I would definitely vote against this whole thing. If we fix all namespaces, how would we know what other namespaces might need to be used in the future? And whenever such new namespaces happen to be needed, someone must again and again update the value of the "fixed-namespaces" attribute ... 😢

The last time the "all or nothing" approach was proven disastrous was by the Germans in WWII.

Totally unacceptable! If this remains unchanged in the Spec then I will never use this new, so called "feature".

I like how this is in XQuery - they have some namespace prefixes bindings fixed, and in addition to this one can declare other namespaces.

[dnovatchev]

@michaelhkay

I looked again at the XSLT 4.0 Spec, and there is no Error defined for the case when a stylesheet module contains an xml namespace declaration that is not contained in the value of the fixed-namespaces attribute.

There is just this sentence (which I and probably most of the group didn't notice when this was discussed):

"If the fixed-namespaces attribute is present, then it defines the entire set of namespace bindings present in the static context of XPath expressions and patterns within the stylesheet".

We need to remove this sentence and this will fix the usability issue. I don't see any pressing issues for this all-or-nothing approach and if there were such, then it needed to be pointed out and well expressed to the members of the group, in order to allow understanding and consequent discussion.

Your thoughts and argumentation will be appreciated.

[michaelhkay]

I would recommend re-reading the original issue: #369 The thread went off at all sorts of tangent, but it does explain the thought process that led us to the current status quo.

In particular I stated three objectives:

• Reduce namespace clutter in the source code.
• Reduce namespace clutter in the static and dynamic context. "Preserving the namespace context in the expression tree through optimization rewrites is a significant cost that has no user benefit"
• Thirdly, prefix clutter in the executable code. Writing math:cos(math:cos($x)) is just so clumsy compared with cos(cos($x)). We dropped this requirement in the course of the discussion.

The current design (including the choice of the name "fixed namespaces") was strongly motivated by the second requirement. Having a fixed set of namespace bindings for the names (like function names and template names) that are normally needed only at compile time is a significant simplification. Replacing this by a design where the fixed-namespaces attribute provides only an initial default set of bindings that can be overridden means either (a) that you have to retain the current expensive cost of keeping these namespaces around at run-time, or (b) that you have a complex set of rules about which namespaces are retained at run-time and which are not. Either way, it means the original objectives of the proposal are not achieved.

[dnovatchev]

Replacing this by a design where the fixed-namespaces attribute provides only an initial default set of bindings that can be overridden means either (a) that you have to retain the current expensive cost of keeping these namespaces around at run-time, or (b) that you have a complex set of rules about which namespaces are retained at run-time and which are not. Either way, it means the original objectives of the proposal are not achieved

The "original objectives of the proposal" have already been revised, and they are not ideal at present either. This is due to the fact that performance factors have been allowed to creep up onto the user surface. Remember what Knuth said?

As a developer I need an unobtrusive way of reducing the non-problem-solving activities of repeatedly specifying standard namespaces again and again, however retaining the ability to create my own namespaces into which to group new, similar functions.

Liberate the developer, not put him in chains.

There is clearly a period of development and then pushing the solution to PROD and using it extensively in production. The current Spec text seems to acknowledge only the 2nd (PROD) period and clearly ignores the specifics and needs for the 1st (DEV).

The developer strongly needs to have the ability and freedom to come up with new groups of functions that need to form their own, non-existent in the past namespace. This DEV requirement is at least as important, if not even more important, as the PROD requirement.

The requirements for the two periods (DEV and PROD) can easily be reconciled by dealing with the new namespaces immediately before pushing to PROD. Ideally this could be accomplished by the IDE, by a separate tool, or by running the XSLT processor with a specific command-line parameter that tells it to transform the XSLT code by placing the unaccounted for namespaces into the fixed-namespaces attribute.

Please, take all this into account and update the Spec (very little needs to be done) so that both requirements have been covered.

[michaelhkay]

Remember what Knuth said?

You're presumably thinking about the famous quote regarding premature optimisation. This is not premature optimisation; it's an attempt to solve a performance problem in the current design that has been known for 20 years.

The performance problem is in fact twofold.

Firstly, namespace bindings that are only needed at compile time (such as namespace prefixes used only for functions names) have to be retained at run-time just in case they are used by one of the features that uses them at run-time, for example casting strings to QNames. This bloats the run-time code.

Secondly, the bloat is increased by the fact that the namespace bindings retained by this mechanism can change for every expression. They actually change more frequently than you might expect, as a result of optimisations such as function inlining which have to retain the namespace context: all in order to achieve a level of conformance that no-one is likely to want or need.

We have studied the performance overheads caused by these effects carefully, and they are substantial; this is not just conjecture.

Now, the main performance win from the feature is the fact that namespaces don't need to be retained at run-time; prefixes can therefore be resolved in an early compilation phase and can then be forgotten. They don't need to be retained at run-time and they therefore don't need to be retained through optimisation rewrites. Once you've achieved this, the fact that namespace bindings change frequently no longer matters very much. But the problem then is that a few namespace bindings DO need to be retained at run-time, for example those used in calls to system-property() or function-available(). So there is a need to distinguish different kinds of namespace declaration, and that's what the fixed-namespaces attribute achieves.

Note that there's a "nudge" factor here. Generally, providing features that only give a performance benefit to expert users is of limited value because many people who could benefit never discover that the feature exists. Delivering a performance benefit and a usability benefit at the same time is much more likely to ensure that the feature becomes widely used "by default".

[dnovatchev]

Note that there's a "nudge" factor here. Generally, providing features that only give a performance benefit to expert users is of limited value because many people who could benefit never discover that the feature exists. Delivering a performance benefit and a usability benefit at the same time is much more likely to ensure that the feature becomes widely used "by default".

This is similar to what I suggested - allow the use of both fixed-namespaces and a few non-fixed ones that the developer may decide to introduce, but automatically convert these non-fixed namespaces to fixed, once directed to do so (on pushes to PROD or by a command-line parameter).

Glad we have general agreement on this.

Then how can we proceed in allowing fixed and non-fixed namespaces to co-exist?