Joseph Kesselman writes:
> On Thursday, 04/24/2003 at 04:39 CET, "Andrew Welch" 
> <[EMAIL PROTECTED]> wrote:
> > back in as the source, but that seems unnecessary.  What I would like to 
> do is 
> > generate sax events for the source based on the variables. Is that 
> feasible?
> 
> "generating SAX events" means "calling methods on a SAX event handler".
> 
> > My confusion lies in the fact that I dont have anything to parse as 
> such, so 
> > when I set the content handler as the source of the transform(which 
> normally 
> > calls parse, right?) what happens?  At what point do I call 
> startDocument() etc
> 
> Ah, I see. Your question is how you pass this information to Xalan.
> 
> One solution: Have your code implement the XMLReader API. You can no-op 
> most of the methods; all you should need to support is getSystemID (which 
> probably returns an empty string, unless you want to give your 
> pseudo-document a systemID that reflects how you're generating it), 
> setContentHandler/setDTDHandler (so we can tell you where to deliver the 
> events), and the parse() methods (which should cause you to deliver your 
> sequence of events to the handlers we passed you). We will call those 
> methods, you'll deliver the data, everything should work.
> 
> Here's something that should be a simpler solution, though I haven't used 
> it: SAXTransformerFactory.newTransformerHandler() constructs a 
> TransformerHandler object. This is a Transformer which implements the 
> ContentHandler/LexicalHandler/DTDHandler APIs, and expects to have the 
> source document delivered to it through these rather than reading from a 
> Source object. All you have to do is tell this where the Result should be 
> sent, send it the correct sequence of SAX events corresponding to the 
> document you're generating, and the Right Thing should happen.
> 
> Note that in either case it's your responsibility to generate a 
> correctly-balanced, well-formed, namespace-aware sequence of SAX events -- 
> and that we do currently expect to see namespace declarations appear as 
> attributes. If your event stream isn't correct, we'll probably 
> malfunction.

I have a question that I posed earlier on the Xerces list, but didn't
get a response on, but it is relevant to this discussion, so I will
ask it again, here:

I have an XMLFilter implemented (as you are suggesting to this
individual) that parses non-XML and generates SAX events.  What is the
best way for me to in fact validate the stream of SAX events against
an XML Schema while processing those same SAX events to perform a
transformation?

-- 
Franklin

Reply via email to