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.
| Summary: | Would be great to have the XSLT editor outside the JBI concept | ||
|---|---|---|---|
| Product: | soa | Reporter: | _ gsporar <gsporar> |
| Component: | XSLT | Assignee: | Alexey Yarmolenko <alexeyyarmolenko> |
| Status: | NEW --- | ||
| Severity: | blocker | CC: | slunegov |
| Priority: | P4 | ||
| Version: | 5.x | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Issue Type: | ENHANCEMENT | Exception Reporter: | |
| Bug Depends on: | |||
| Bug Blocks: | 112118 | ||
|
Description
_ gsporar
2007-02-15 06:46:04 UTC
We considered such oportunity, but discovered several problems on this way: 1. Mapper relies on other artifacts found in JBI project(such as xsltmap.xml and .wsdl) to know its input and output types. We cant show source and target trees without this information. To bypass this restriction we should give user a way to specify schemas for input and output document and persist this informathion somewhere between editing sessions. 2. Existing mapper supports very limited subset of XSLT instructions. For example, it DOES NOT support xsl:template, xsl:apply-template, etc. This limitation is dificult to avoid from implementation point o view. So, current mapper can be considered to be a tool to draw simple transformations, but not as all-purpose XSL editing tool. Depending on our resource allocation, we can try to fix #1 in hula release timeframe. But fixing #2 may require some new ideas on implememntation and usage workflow. Just FYI, some VOC here: http://www.netbeans.org/servlets/ReadMsg?list=nbentpack&msgNo=1000 Obsolete milestone, please reevaluate Not critical. Changed to P4. |