This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 19439 - XSL Transformation action
Summary: XSL Transformation action
Alias: None
Product: xml
Classification: Unclassified
Component: Tools (show other bugs)
Version: 3.x
Hardware: PC Other
: P1 blocker with 1 vote (vote)
Assignee: _ lkramolis
: 20799 (view as bug list)
Depends on: 21851
  Show dependency tree
Reported: 2002-01-15 02:24 UTC by robertmcauliffe
Modified: 2007-09-25 01:33 UTC (History)
0 users

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description robertmcauliffe 2002-01-15 02:24:28 UTC
It would be nice if the user could right click on an XML document and transform 
it with an XSL document.

The XSL document chosen and destination location should be based on either of 
the following:

 1 - Properties in the property sheet for the XML document if they are set, 

 2 - The reference to an XSL file in the content of the XML document, if the 
reference exists, otherwise:

 3 - The user is prompted for information not filled in from the above sources.
Comment 1 _ lkramolis 2002-02-05 08:17:39 UTC
Copy-paste from nbusers mailing list.

-------- Original Message --------
Subject: [nbusers] XSLT development
From: Daryl Stultz

I find that the development of XSLT projects works best when the
stylesheet is not declared in the XML. I model web pages with XML and
apply XSLT to get the HTML. The XSL file to use is not specified in the
XML - that way I can switch the XSL any time to get different views of the

A proper XSLT dev environment involves editing an XML doc in one view,
XSLT in another and then transforming to HTML or whatever. (The transform
action should remember the last stylesheet and run from a shortcut since
it will happen a lot.)

CookTop is a very good environment for this - but it's all text based.

Merlot is a good Java XML editor but lacks support for XSLT doc editing.
Apparently the DTD is challenging since you can mix in non-namespaced tags
of your choice.

Daryl Stultz
Comment 2 robertmcauliffe 2002-02-05 22:01:01 UTC
The above is fair enough.  I think it would probably suit most 
development styles to assign an XSL file in the property sheet/when 
prompted, however, I would postulate that there are some that use the 
definition in the XML file (as we have at times).  I would see it as 
a lower priority than the ability to assign an XSL file in the 
property sheet or when prompted, but useful nonetheless.

Ideas anyone?
Comment 3 _ lkramolis 2002-02-25 09:59:50 UTC
*** Issue 20799 has been marked as a duplicate of this issue. ***
Comment 4 brunovernay 2002-03-01 08:31:52 UTC
I agree with Daryl Stultz : Having a XSLT developpement environnement
would be great.  I use NetBeans for XML only (I put out all the other
modules.) and DocBook.

Comment 5 _ lkramolis 2002-03-05 17:20:10 UTC
First draft of User View is done.
Comment 6 _ lkramolis 2002-03-06 08:34:46 UTC
Must have feature.
Comment 7 _ lkramolis 2002-03-19 17:58:05 UTC
Please, could you review User View document?

Comment 8 robertmcauliffe 2002-03-20 00:58:33 UTC
Some comments on the user view document:

When a user performs a transformation, I would see three outcomes 
that they could want:

    1 View the result;
    2 Save the result to a file; or
    3 Both of the above.

I think the user interface should reflect this fundamental choice.  
Also, if the user is viewing, they may want to view in the browser, 
or in the source editor/default action.  So I think the interface 
should present a choice between the above main options, followed by 
an option to provide extra information based on the first choice.  So 
if saving was desired, an output filename choice is available, if 
viewing is chosen the viewing action choice is available.

The only problem with this that I can see is how to represent that 
initial choice.  you could have two checkboxes with the artificial 
constraint that at least one must be selected, or you could have a 
drop-down with three choices, 'save', 'view', or 'save and view'.  I 
think both of these aren't particularly desirable, the first because 
it's not how the user expects that control to work, the second 
because the choices in the drop-down aren't mutually exclusive.  I 
suppose without any other options, the second is the more desirable 
of the two.

So the interface could look like this:

|                                           |
|  XML Source:  ############\/  |Browse...| |
|  XSL Script:  ############\/  |Browse...| |
|                                           |
|  Action(s):   ############\/              |
|                                           |
|  Output To:   ############\/  |Browse...| |
|  View In:     ############\/              |
|                                           |
|                      | OK |   |Cancel |   |
|                                           |


|                                           |
|  XML Source:  ############\/  |Browse...| |
|  XSL Script:  ############\/  |Browse...| |
|                                           |
|  [] Save to File                          |
|                                           |
|  Save To:     ############\/  |Browse...| |
|                                           |
|  [] View Output                           |
|                                           |
|  View In:     ############\/              |
|                                           |
|                      | OK |   |Cancel |   |
|                                           |

With the appropriate controls disabled.

For the issues:

Transformation of mulitple XML documents being shown in the one 
window would create multiple outputs (meaning the user would have to 
specify multiple targets), so I think it would complicate the user 
interface too much to support multiple transformations in that way.

The other option is you could open a window for each file selected so 
that the user could enter the details for each to be transformed.  
Optionally the same sort of mechanism as the exception window could 
be used (all windows in the same frame, next to go to the next window 
shown, with the addition of OK closing the current but not the 

In terms of suporting DocBook, It would probably be good to have some 
default XSLs in a particular folder, and this could include DocBook 
ones (assuming I've understood what is meant by 'support').  How to 
access them through the UI, I'm not sure.  Maybe they could be the 
initial populators of the most recently used drop down.  I think it 
would be annoying to have that directory the default for the initial 
browse location, so that's probably not good.

In terms of supporting FOP: it would probably be useful, but I'm not 
sure how high priority for the first inclusion of transformations.   
If it is included, I guess it should be done in a general way so that 
other processors could be easily added later.

Since FOP would be a different kind of interaction than a normal 
transform, if included it should be a different window and menu item 
(possibly a sub-menu which lists all attached processors).  I know 
almost nothing about FOP, so I'm not sure what (if anything) would be 
required from the window.

Comment 9 brunovernay 2002-03-20 09:54:45 UTC
I think that NetBean should provide  : 
- a simple and intuitive way of processing XSLT. (One XML, one XSLT,
one Output.)
- a way to execute an external script (windows or unix), eventually
shows the processing output in a NetBean windows (like a compilator),
and let the user refresh his browser or anything he uses to view the
resulting files (wich can be numberous and various.)

This way : it stays simple and extensible. (Conserning Docbook, I use
many XML files keep together with an entity file, SAXON and FOP to
process the data and there are many html PDF ans PS files as output.)
Comment 10 robertmcauliffe 2002-03-20 10:40:58 UTC
Bruno: I'm not sure I understand the second point, do you mean:
All transformations and viewing should be performed by an external
script, with the output viewed in text form in the output window in
the same fashion as the compiler?  And any external viewing of the
file is accomplished by the user pointing his/her browser to the
appropriate output file?

Comment 11 brunovernay 2002-03-20 11:02:23 UTC
I mean that we can't avoid an external script for complex processing
of XML files. 

> with the output viewed in text form in the output window in
> the same fashion as the compiler?  
YES, the ouptut of the processing information, like "Error in XSLT
line 5468 ..."

> And any external viewing of the
> file is accomplished by the user pointing his/her browser to the
> appropriate output file?

Yes and refresh when a new transformation is made.
Comment 12 K.C. Baltz 2002-03-22 16:15:44 UTC
I would like to have the option of retrieving the input 
XML from a URL.  This would make it easier to test XSLT on 
dynamically generated XML.  
Comment 13 _ lkramolis 2002-03-25 11:01:18 UTC
User View document as sub-task (issue #21851) of this feature.
Comment 14 _ lkramolis 2002-03-25 15:06:55 UTC
First of all, thank you for your time you spent you wrote suggestions.

Robert, I do not see big difference between your suggested UI changes
and mime proposed one. You just add check boxes (Save to File|View
Output) and same actions I provide by combo boxes.

Reason why I have introduced such UI is following. Typically, you have
(1) XML source, (2) XSLT script and (3) want to create output or just
preview -- first three rows of components. Bonus: if you create output
file, you can do some special action with it - view, edit, ... --
'Process Output'.

The only problem I see is that you can find 'Preview' or 'View' in two
places but I think both are logical.

It looks Multiple transformations would be useful, so I will propose
posible solutions at users@xml.

Bruno have inspired me to think about XSLExecutor API (similar to Java
Executor) and FOP could be supported by another XSLExecutor
implementation in later phase. Each XLSExecutor would provide its own UI.

K.C., it make sense to support URL for XML source and also for XSLT
script. Thanks.

I would like to ask, could we move 
discussion to, it begin to be so long. We could
use this report to trace final decision. Thanks.
Comment 15 robertmcauliffe 2002-03-27 10:11:03 UTC
I probably should have made it more clear what angle I was making my
comments from.  I was giving suggestions from a tweaking point of
view, not from the point of view of making functional changes.  The
same functions are available (probably equally conveniently) from
both, and, as such, I don't see the current design as a real problem.

What I was thinking was that since the main things a user is
interested in are as I stated, these should be the things that the
user initially chooses. So if the user wants to view, that is the
control that is available to him/her - the save control is not
available (and vice-versa if the user wants to save and not view),
trying to make the flow of the user interface be the flow of the
required decisions (of the user) so that it is easier to use.

I don't know if I can explain what I mean properly...

Comment 16 _ lkramolis 2002-04-25 21:29:18 UTC
Simple action implemented.

Enhanced support will be addressed by next release.
Comment 17 _ lkramolis 2002-05-06 08:09:22 UTC
UI should be reviewed by UI experts (issue #22841) and also documented
(issue #22931).
Comment 18 dmladek 2004-08-19 10:08:24 UTC
ok, done