Re: [xsl] Re: Language-specific output

Subject: Re: [xsl] Re: Language-specific output
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Fri, 03 Feb 2006 11:15:24 -0500
Dear George,

At 07:30 AM 2/3/2006, you wrote:
I also tend to agree up to some point with Dimitre. That is the validation by creating a transformer may be a little too much for a module. But removing the validation completely and have that only when running a transformation I think it is not a good idea especially when automatic validation is taken into account.

I am really liking the validation-in-the-background feature of the new oXygen. In particular, I'm liking the way syntactically malformed XPath expressions (or pseudo-XPath since they're malformed) just "light up" on their own, rather than just lurking till runtime before I discover I have one too few closing parentheses.

While I think Dimitre's point is excellent, it bears on the original observation that you and Mike made, namely that modules can work within a modular architecture even when they don't work standalone, as much as on the problem you pose. As you imply, if automatic validation in the background is a requirement, the toolmaker is faced with a problem of how to support it.

A possibility to avoid the what Dimitre calls "overvalidation" will be to perform a validation of the XSLT document against an XSLT schema for instance. A possible implementation may be to allow the user to specify the level of validation he wants for stylesheets:
* validate against a schema
* using an XSLT processor

Yes, plus perhaps an in-between option:

* validate against a schema
* validate against a schema + an XPath parser
  (or even against a schema- or source-aware XPath processor?)
* using an XSLT processor

In any case the validation is not the only operation when having a master stylesheet specified will be good. Take for instance the content completion, when the user should see the available variables that he can use at some point or the names of the templates he can call. Maybe having a persistent mapping called "set main stylesheet" will be the best. That should be controlled from a set main stylesheet action that should act also on multiple files (so that the user can just select a folder for instance in the project and set the main stylesheet in one action for all the XSLT files in that folder). The stylesheets that have a main stylesheet set can be then marked as modules (by decorating their icon for instance) so that the user can easily see he is editing a module.
More, I think the need for having a main document property is more general and may be applied also to XQuery, Relax NG schemas and even to XML documents (consider a document that is included in the main document through an external entity reference and that may not be valid or wellformed by itself).

All this seems quite reasonable to me. I think it's interesting how Dimitre's critique points out how XSLT (with its XML syntax etc.) is something between a markup language, for which extra-process validation is a useful and even necessary thing, and a programming language, for which a conformant processor is the only thing that "validates" in any really meaningful way. Dimitre is correct, it seems to me, that XSLT is really the latter. But that doesn't stop us from wanting features we come to expect from the former, looser kind of application, and which XSLT can even support, up to a point and given a little help.


Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.      
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
  Mulberry Technologies: A Consultancy Specializing in SGML and XML

Current Thread