[xsl] Auto-complete for schema-aware XSLT 2.0

[Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>]

George Cristian Bina wrote:
> The difficult part IMO is to establish the context, both for XPath
> expressions (on the source schema) and for content completion (on
> the result schema). One problem is that in XML Schema the element
> name and namespace are not enough to identify the context because
> there can be any number of local elements with the same name but
> different definitions. The context is formed by the whole path to
> the root and this is difficult and maybe impossible to find inside a
> stylesheet. A possible solution will be to present the union of the
> matching proposals.

This is something where a good XSLT 2.0 coding style and schema-aware
processing can help.

In XPath 2.0, schema-aware node tests can point to particular element
or attribute declarations, or to types defined in a schema. For
example "schema-element(table)" matches any element that has the same
name and type as that declared by the top-level element declaration
for the <table> element or any member of its substitution group.

So if you have a path that starts with "schema-element(table)" then
you have a basis for providing auto-completion on the rest of the
path: you might know, for example, that the only child elements that
are legal are <thead>, <tbody> and <tfoot>, and offer those options.

Similarly, if you have a template whose match pattern is
"schema-element(table)/tbody" then you know that the context node
within that template is a <tbody> element that's valid against the
type declared for the <tbody> element within a <table> element, as
declared in the global element declaration in the schema.

And if you have a template that has an "as" attribute of
"schema-element(table)", you know that the element that the template
generates must match that particular element declaration.

If you have a <table> literal result element with
xsl:validation="strict", then you can similarly work out that the
<table> element must be valid against the top-level element
declaration for the <table> element. The [xsl:]type attribute can be
used in a similar way.

Schema-aware XSLT 2.0 processors can, of course, pick up on the same
clues to help them optimise processing and to provide helpful error
messages when they read the stylesheet, telling you if you've spelt an
element name incorrectly and so on.

But you only get the benefit of all this if you're rigorous in your
coding: using schema-element() node tests rather than just the name of
the element, and using the "as" attribute and xsl:validation/xsl:type.
That can be a lot of work, and using any of these features will, of
course, mean that your stylesheet is only usable with a schema-aware
XSLT processor.

I'd like to see the above mechanisms provide a "strict" level of
auto-completion and static checking, in which programmers are actually
limited to only generating legal paths and result trees. But I'd also
like to see editors and processors providing a "lax" level of
checking. Under the lax mode, the processor would, as George
suggested, use the union of the possibilities to offer hints and
provide warnings, but still allow the programmer to name elements that
aren't actually permitted according to the schema. An editor or
processor could offer this support without the stylesheet actually
importing any schemas (with <xsl:import-schema>), which would help
writers of non-schema-aware XSLT 2.0 as well.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/