Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xsl] Re: Language-specific output

From: Wendell Piez <wapiez@---------------->
To:
Date: 2/2/2006 5:55:00 PM
Dear George,



If a stylesheet isn't valid on its own when the user initiates 
validation, perhaps the user could be prompted to nominate another 
stylesheet (i.e. the main one) to validate in its place. Perhaps this 
setting could be "sticky" in a session.



That is, I'm in favor of option 1, except I'd like the default 
behavior to be to validate this stylesheet, with the option of 
validating another one offered only if there's trouble.



As far as the difficulty of having many of these to set when an 
import tree is complex, perhaps this is the point when heuristics 
could be applied to a project, and a likely candidate or candidates 
for "main stylesheet" nominated in a pick-list. That would alleviate 
some of the burden, while allowing developers to retain control.



I've sometimes had modules that had more than one calling stylesheet, 
after all (it's part of the point of a modular design), so I'd rather 
not leave this completely up to the machine to decide.



Cheers,
Wendell

At 08:20 AM 2/2/2006, you wrote:
When you perform a stylesheet validation in oXygen it tries to 
create a Transformer out of that using the XSLT processor you have 
configured for XSLT validation. By default that is Saxon 6.5.5 for 
XSLT 1.0 and SaxonB 8.6.1 for XSLT 2.0.



Now it is true that some stylesheets are not valid by themselves but 
are ok if they are imported or included from other stylesheets. In 
fact this is one of the things we discussed recently internally at 
oXygen and I would like to get some feedback from XSLT users. 
Basically for a stylesheet module (that is not intended to be used 
by itself) the validation should be performed on the main stylesheet 
(on the one that includes/imports directly or indirectly the module).



Now the problem is how that situation is handled:



1. One possibility is to allow the user to specify the main 
stylesheet through some action (for instance click on a button and 
enter the main stylesheet in a dialog).



2. Another approach is to analyze all the stylesheets from the 
current project and see how they are related wrt include/import and 
determine automatically the main stylesheet.



Both these approaches have bad points.



In the first case if there are a lot of modules the user has to make 
a lot of actions to specify for each module the main stylesheet and 
that may be annoying.



In the second case analyzing all the stylesheets in the project can 
take some time and after doing that it is possible to get more 
possible master stylesheets and in that case the user action will be 
required to determine the actual main stylesheet to be used.



So, what would you prefer? If you want to work in a totally 
different way, how would that be?



Best Regards,
George
---------------------------------------------------------------------
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
www.---.com




======================================================================
Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
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
======================================================================


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent