Subject: [xsl] Auto-complete for schema-aware XSLT 2.0 From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx> Date: Tue, 9 Nov 2004 14:32:03 +0000 |
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/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XML/XSL free editor (ecli, George Cristian Bina | Thread | Re: [xsl] Auto-complete for schema-, Wendell Piez |
RE: [xsl] XML/XSL free editor (ecli, Michael Kay | Date | Re: [xsl] Grouping by key - another, gopinath . emmidiset |
Month |