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.
Cheers,
Wendell
======================================================================
Wendell Piez
mailto:wapiez(_at_)mulberrytech(_dot_)com
Mulberry Technologies, Inc. http://www.mulberrytech.com
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
======================================================================
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--