Change default query language binding

[xatapult]

The default query language binding is xslt, meaning that you're limited to XPath 1.0. That is severely limiting nowadays.

Why not keep the default query language binding in check with the current state of technology? My proposal would be to make xslt3 the default, but xpath31 would also be a good candidate.

[tgraham-antenna]

The default query language binding is xslt, meaning that you're limited to XPath 1.0. That is severely limiting nowadays.

You have always been limited to what your Schematron processor supports.

Schematron 2016, Clause 6.4, "Query language binding", includes "A Schematron implementation which does not support the query language binding, specified in a schema with the queryBinding attribute, shall fail with an error." It is arguably a hole in Schematron 2016 that this doesn't also mention the absence of a queryBinding attribute, but I would expect a pure XQuery implementation, for example, to fail with an error when queryBinding is absent.

People have been using queryBinding="xslt2" for years. An exchange such as this in advance of Schematron 2016 would probably have seen arguments for making xslt2 the rational default.

I also expect that most <schema> elements are either generated from a template or copied from an existing Schematron file, meaning that few people have to stop to think about the queryBinding value anyway.

Why not keep the default query language binding in check with the current state of technology? My proposal would be to make xslt3 the default, but xpath31 would also be a good candidate.

And backwards compatibility? Interoperability?

What if XSLT 4 becomes the current state of technology during the five-year span of the next Schematron version? What if Schematron stalls again and the next version lingers on for longer than five years while our definitions of 'the current state of technology' progresses?

[rjelliffe]

It would be better to have no default than to change the default. There are still many people using MSXML and XSLT1.

If you change the default, then people who have XSLT styesheets that do work will have them (formally) not work.

The QLB attribute was an attempt to do the simplest thing that could work. (Which is why it is not a URL, for example, along the lines of all the utterly bogus URLs that were made under the bright-eyed influence of the W3C and RDF people.)

However, it has been compromised to an extent because of strange position I think I detect from e.g. Michael Kay (with no disrespect!) which treats the XSLT 1, 2, 3 as if they are just minor version numbers (so version 2 supersedes v1, etc) whereas they are major version numbers (which an organization tends to freeze on a version for the lifetime of a system).

So this idea that "xslt" = whatever the most recent versions is, comes out of that mentality, I think. It is utterly wrong IMHO. More than that, I think it reflects a vendor-side POV (though obviously not MS in this instance!)

What is the purpose of the QLB attribute? It is to make sure that a Schematron implementation configures itself correctly for the conventions that the schema was written using, and to block unsupported query languages: especially important given that we cannot guarantee that XPath 1, 2, 3, etc implementations will give the same results for the same query string: it is not an assumption we can make (it is the W3C XSLT WG or whoever's).

If the default is changed to xslt3, say, and I make a stylishness using the default, and I send it to someone with an existing system, it won't fail before compilation with a clear message: instead it may fail at compile time with a message like "xsl:blahblah not defined for XSLT1 (assuming the standard QLB binding for xslt3 allows more foreign elements) or at runtime with a cryptic "Xpath syntax error: unexpected token blahblah". User: huh?

So then, the call will go up to transfer which version of the standard a schema belongs too, and silly people will want to change the Schematron namespace and bingo we are in hell. (If the XML namespaces mechanism had been defined with a major/minor version convention, we would be in a better position.)

The thing is, the QLB system and attribute seems to have worked fine for 18-ish years. Now everyone who writes a schema may grumble about being forced to know what they are doing, and may wish that their systems particular version of XSLT were the default. But it saves keystrokes: Oxygen and any IDE will help fill it in, and having removes the need for the schema runner to have a parameter.

The worst thing would be if the poor receiver of a schema needed to look through every XPath to see which version was being used. I have had schemas with thousands of assertions: not fair.

Schema languages really are things that must not change the result that they give, surely?

Regards, Rick

On Wed, 6 Apr 2022, 10:32 pm Tony Graham, @.***> wrote:

The default query language binding is xslt, meaning that you're limited to XPath 1.0. That is severely limiting nowadays.

You have always been limited to what your Schematron processor supports.

Schematron 2016, Clause 6.4, "Query language binding", includes "A Schematron implementation which does not support the query language binding, specified in a schema with the queryBinding attribute, shall fail with an error." It is arguably a hole in Schematron 2016 that this doesn't also mention the absence of a queryBinding attribute, but I would expect a pure XQuery implementation, for example, to fail with an error when queryBinding is absent.

People have been using queryBinding="xslt2" for years. An exchange such as this in advance of Schematron 2016 would probably have seen arguments for making xslt2 the rational default.

I also expect that most elements are either generated from a template or copied from an existing Schematron file, meaning that few people have to stop to think about the queryBinding value anyway.

Why not keep the default query language binding in check with the current state of technology? My proposal would be to make xslt3 the default, but xpath31 would also be a good candidate.

And backwards compatibility? Interoperability?

What if XSLT 4 becomes the current state of technology during the five-year span of the next Schematron version? What if Schematron stalls again and the next version lingers on for longer than five years while our definitions of 'the current state of technology' progresses?

— Reply to this email directly, view it on GitHub https://github.com/Schematron/schematron-enhancement-proposals/issues/28#issuecomment-1090213936, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF65KKMIBE5BYPV4PFXCYJLVDV75LANCNFSM5SU7GWKQ . You are receiving this because you are subscribed to this thread.Message ID: <Schematron/schematron-enhancement-proposals/issues/28/1090213936@ github.com>

[rjelliffe]

I meant "formerly" not "formally": my secretary, Samsung, made the error. Apologies.

On Thu, 7 Apr 2022, 11:31 pm Rick Jelliffe, @.***> wrote:

It would be better to have no default than to change the default. There are still many people using MSXML and XSLT1.

If you change the default, then people who have XSLT styesheets that do work will have them (formally) not work.

The QLB attribute was an attempt to do the simplest thing that could work. (Which is why it is not a URL, for example, along the lines of all the utterly bogus URLs that were made under the bright-eyed influence of the W3C and RDF people.)

However, it has been compromised to an extent because of strange position I think I detect from e.g. Michael Kay (with no disrespect!) which treats the XSLT 1, 2, 3 as if they are just minor version numbers (so version 2 supersedes v1, etc) whereas they are major version numbers (which an organization tends to freeze on a version for the lifetime of a system).

So this idea that "xslt" = whatever the most recent versions is, comes out of that mentality, I think. It is utterly wrong IMHO. More than that, I think it reflects a vendor-side POV (though obviously not MS in this instance!)

What is the purpose of the QLB attribute? It is to make sure that a Schematron implementation configures itself correctly for the conventions that the schema was written using, and to block unsupported query languages: especially important given that we cannot guarantee that XPath 1, 2, 3, etc implementations will give the same results for the same query string: it is not an assumption we can make (it is the W3C XSLT WG or whoever's).

If the default is changed to xslt3, say, and I make a stylishness using the default, and I send it to someone with an existing system, it won't fail before compilation with a clear message: instead it may fail at compile time with a message like "xsl:blahblah not defined for XSLT1 (assuming the standard QLB binding for xslt3 allows more foreign elements) or at runtime with a cryptic "Xpath syntax error: unexpected token blahblah". User: huh?

So then, the call will go up to transfer which version of the standard a schema belongs too, and silly people will want to change the Schematron namespace and bingo we are in hell. (If the XML namespaces mechanism had been defined with a major/minor version convention, we would be in a better position.)

The thing is, the QLB system and attribute seems to have worked fine for 18-ish years. Now everyone who writes a schema may grumble about being forced to know what they are doing, and may wish that their systems particular version of XSLT were the default. But it saves keystrokes: Oxygen and any IDE will help fill it in, and having removes the need for the schema runner to have a parameter.

The worst thing would be if the poor receiver of a schema needed to look through every XPath to see which version was being used. I have had schemas with thousands of assertions: not fair.

Schema languages really are things that must not change the result that they give, surely?

Regards, Rick

On Wed, 6 Apr 2022, 10:32 pm Tony Graham, @.***> wrote:

The default query language binding is xslt, meaning that you're limited to XPath 1.0. That is severely limiting nowadays.

You have always been limited to what your Schematron processor supports.

Schematron 2016, Clause 6.4, "Query language binding", includes "A Schematron implementation which does not support the query language binding, specified in a schema with the queryBinding attribute, shall fail with an error." It is arguably a hole in Schematron 2016 that this doesn't also mention the absence of a queryBinding attribute, but I would expect a pure XQuery implementation, for example, to fail with an error when queryBinding is absent.

People have been using queryBinding="xslt2" for years. An exchange such as this in advance of Schematron 2016 would probably have seen arguments for making xslt2 the rational default.

I also expect that most elements are either generated from a template or copied from an existing Schematron file, meaning that few people have to stop to think about the queryBinding value anyway.

Why not keep the default query language binding in check with the current state of technology? My proposal would be to make xslt3 the default, but xpath31 would also be a good candidate.

And backwards compatibility? Interoperability?

What if XSLT 4 becomes the current state of technology during the five-year span of the next Schematron version? What if Schematron stalls again and the next version lingers on for longer than five years while our definitions of 'the current state of technology' progresses?

— Reply to this email directly, view it on GitHub https://github.com/Schematron/schematron-enhancement-proposals/issues/28#issuecomment-1090213936, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF65KKMIBE5BYPV4PFXCYJLVDV75LANCNFSM5SU7GWKQ . You are receiving this because you are subscribed to this thread.Message ID: <Schematron/schematron-enhancement-proposals/issues/28/1090213936@ github.com>

[AndrewSales]

I'm making no change to the 2025 draft about the default, only to make it explicit (in regard to @tgraham-antenna 's point) that, if unspecified, the default applies.