XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (777 page)

With
group-by
, a node can be assigned to multiple groups by calculating multiple grouping keys, but this isn't allowed with
group-adjacent
.

XTTE1120

When
xsl:for-each-group
has a
group-starting-with
or
group-ending-with
attribute, the value of the
select
attribute must not contain atomic values

These attributes are patterns that only match nodes, so the input (the grouping population) must consist entirely of nodes.

XTTE1510

When
[xsl:]validation=“strict”
is specified, the constructed content must be valid

This is a catch-all error code for schema validation errors. Hopefully, the processor will provide more detailed information as to why the constructed content was found to be invalid against the schema.

XTTE1512

When
[xsl:]validation=“strict”
is specified, there must be a matching top-level element declaration in the schema

Validation was not possible because no element declaration could be found for the root element. Check that the namespace is correct.

XTTE1515

When
[xsl:]validation=“lax”
is specified, the constructed content must have validity either “valid” or “unknown”

This means that an element declaration was found (or perhaps there was an
xsi:type
attribute), so validation took place, but the content was invalid against the schema. See XTTE1510.

XTTE1540

When
[xsl:]type
is specified, the created content must be valid against that type

See also XTTE1510. This code is reported when validation was invoked against a named type.

XTTE1545

An instruction with an
[xsl:]type
or
[xsl:]validation
attribute must not create a new attribute node with namespace-sensitive content

This happens when you do validation at the level of an individual attribute node. If the attribute type is QName or
NOTATION
, validation is not possible because the attribute is not connected to any element, so there are no namespaces to check against.

XTTE1550

When validation is done at document level, the document node must contain exactly one element child and no text nodes

The XDM model allows document nodes with no children, multiple element children, or child text nodes, but such documents are never schema-valid.

XTTE1555

When validation is done at document level, ID/IDREF constraints must be satisfied

Specifically,
ID
values must be unique, and
IDREF
values must refer to an
ID
that exists within the document.

Appendix C

Backward Compatibility

The designers of XSLT 2.0 and XPath 2.0 took a great deal of care to ensure that existing code should continue to work unchanged as far as possible, and in my experience, moving forward to 2.0 rarely causes any compatibility problems. However, because there are so many new features, and particularly because of the changes in the type system, a few incompatibilities were inevitable. This appendix summarizes the areas where you are most likely to encounter problems. It's not a completely comprehensive list; for that, you should go to the relevant appendices of the W3 C specifications for XSLT 2.0, XPath 2.0, and
Functions and Operators
. However, many of the incompatibilities described in those appendices are such obscure edge cases that you are very unlikely to encounter them in practice.

You can think of the transition from XSLT 1.0 to XSLT 2.0 as happening in three stages, though you may choose to do all three at once:

• The first stage takes the stylesheet unchanged, still specifying
  version=“1.0”
  , and runs it under an XSLT 2.0 processor instead of an XSLT 1.0 processor.
  
• The next stage is to change the stylesheet to specify
  version=“2.0”
  . This has the effect of switching off backward-compatibility mode.
  
• The final stage is to modify the stylesheet to take advantage of new facilities introduced in XSLT 2.0 and XPath 2.0; notably, the ability to validate the source documents against a schema.
  

There is potential for transition problems to occur at each of these three stages. The focus in this appendix, however, is on the first two stages, because once you start changing your stylesheet or your application, it's very much under your own control whether existing code keeps working.

In this appendix we'll treat the XSLT changes and the XPath changes together.

It's important to remember that we can only talk here about changes in the W3 C language specification. The W3 C specifications leave many options open to implementors, so there may be incompatible changes to products that are not described here. Some of these may be triggered by the change in language specification—for example, an API for passing parameters to a stylesheet may change to accommodate the larger number of data types allowed, or vendors may have dropped support for extension functions that duplicate XSLT 2.0 functionality. But that's entirely a matter for product vendors to sort out.

Stage 1: Backward-Compatibility Mode

This section describes the incompatibilities that can occur when you are running in backward-compatibilty mode enabled (that is, with a stylesheet that specifies
version=“1.0”
). It is important to remember that even in this mode, you are using the XPath 2.0 data model rather than the XPath 1.0 data model and that this causes some inevitable differences.

XSLT 2.0 processors are not required to support backward-compatibility mode. If you request it (by specifying
version=“1.0”
), then such a processor must report a fatal error. Alternatively (and this is what XML Spy does), your development environment may use the
version
attribute to decide whether to launch a 1.0 or a 2.0 processor.

Deprecated Facilities

The use of
disable-output-escaping
is now deprecated. It was always an optional feature in XSLT 1.0, and did not work in all environments (a notable example being the Firefox browser). The fact that it is deprecated in 2.0 means that more vendors may decide to drop support.

XPath 2.0 states that “the namespace axis is deprecated and need not be supported by a host language”. XSLT, however, states that if backward-compatibility mode is in effect, then the namespace axis must be supported.

Error Handling

XSLT 1.0 described a large number of situations as “recoverable errors”. Essentially this phrase means that if you (as the stylesheet author) do something questionable, the processor can either report an error or recover in a defined way.

In XSLT 2.0 many of these errors have become non-recoverable, so an XSLT 2.0 processor will behave like a 1.0 processor that reported the error. For example, if you try to create an attribute with an invalid name, or if you try to create an attribute for an element after creating its text content, the processor will now report an error—in 1.0, it might have simply ignored the attempt to create the attribute. These changes can trip you up if you were previously using an XSLT 1.0 processor that was forgiving about such errors.

In a few cases, XSLT 2.0 has standardized on the recovery behavior instead. So if you try to create a comment containing two adjacent hyphens, the processor will now insert a space between the hyphens.

Some other errors remain recoverable at processor discretion: notable examples are having two template rules that match the same node and calling the
document()
function to retrieve a document that doesn't exist. Different processors may behave differently in these situations.

There is one particular case where the behavior in 2.0 (even in backward-compatibility mode) is different from both the error behavior and the recovery behavior in 1.0. This arises if you try to supply an element node when constructing the value of a new attribute node, for example:

In 1.0 this either would cause an error or would give you an empty attribute. In 2.0, the new attribute is created, and its value is
23
(the result of atomizing the element).