[ http://nagoya.apache.org/jira/browse/XALANJ-1080?page=history ]

Henry Zongaro updated XALANJ-1080:
----------------------------------

      Assign To:     (was: Xalan Developers Mailing List)
           type: New Feature  (was: Bug)
    Description: 
Just got a request from someone who'd like to avoid generating DOM fragments, 
and would prefer to pass us a series of SAX events to be included into the 
output stream. This has obvious hazards (a DOM tree enforces a certain amount 
of 
consistancy that a SAX stream doesn't) but I can see a possible efficiency 
argument.

Two possible approaches:

1) Allow extensions to return a SAXSource (or XMLReader), which we would then 
connect up and invoke to drive its output into our stream.

2) Allow extensions to request a listener that they could deliver events to. 
That'd be much simpler for extensions which just want to produce a bit of 
hardcoded structure, in-line. (I think it's actually possible to do this now by 
delivering events directly to the transformer's result tree handler... but that 
isn't tested or documented, and there may be questions of when this occurs 
versus other events in the vicinity of the extension.)

May be too hazardous, but worth a closer look.

  was:
Just got a request from someone who'd like to avoid generating DOM fragments, 
and would prefer to pass us a series of SAX events to be included into the 
output stream. This has obvious hazards (a DOM tree enforces a certain amount 
of 
consistancy that a SAX stream doesn't) but I can see a possible efficiency 
argument.

Two possible approaches:

1) Allow extensions to return a SAXSource (or XMLReader), which we would then 
connect up and invoke to drive its output into our stream.

2) Allow extensions to request a listener that they could deliver events to. 
That'd be much simpler for extensions which just want to produce a bit of 
hardcoded structure, in-line. (I think it's actually possible to do this now by 
delivering events directly to the transformer's result tree handler... but that 
isn't tested or documented, and there may be questions of when this occurs 
versus other events in the vicinity of the extension.)

May be too hazardous, but worth a closer look.

    Environment: 
Operating System: Other
Platform: Other

  was:
Operating System: Other
Platform: Other

       Priority: Major
    Bugzilla Id:   (was: 10603)

> Allow extension to return SAX events?
> -------------------------------------
>
>          Key: XALANJ-1080
>          URL: http://nagoya.apache.org/jira/browse/XALANJ-1080
>      Project: XalanJ2
>         Type: New Feature
>   Components: Xalan-extensions
>     Versions: CurrentCVS
>  Environment: Operating System: Other
> Platform: Other
>     Reporter: Joe Kesselman

>
> Just got a request from someone who'd like to avoid generating DOM fragments, 
> and would prefer to pass us a series of SAX events to be included into the 
> output stream. This has obvious hazards (a DOM tree enforces a certain amount 
> of 
> consistancy that a SAX stream doesn't) but I can see a possible efficiency 
> argument.
> Two possible approaches:
> 1) Allow extensions to return a SAXSource (or XMLReader), which we would then 
> connect up and invoke to drive its output into our stream.
> 2) Allow extensions to request a listener that they could deliver events to. 
> That'd be much simpler for extensions which just want to produce a bit of 
> hardcoded structure, in-line. (I think it's actually possible to do this now 
> by 
> delivering events directly to the transformer's result tree handler... but 
> that 
> isn't tested or documented, and there may be questions of when this occurs 
> versus other events in the vicinity of the extension.)
> May be too hazardous, but worth a closer look.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to