> Hi Kohsuke, > > Many thanks for the response. Any no apologies required for missing the > point - my original posting was not sufficiently clear. I will try again. > > I have an XML document with an xinclude/xpointer element in it. > > The included document may itself have an xinclude element, and so on.
Right, but it shouldn't matter. Because I think you can process XInclude in such an order that your included fragment doesn't need any further inclusion processing. > One feature of xpointer is for it to select the element from the included > document based on its schema-determined ID. So, your XInclude XNI component should sit before the validator, and when you find an inclusion, you build another pipeline (and this time you sit at the end of the new pipeline), and let it parse the document. This new pipeline could include your XInclude XNI component, or it may include a validator. In either way, by the time your handler (which is the last component in the pipeline) receives events, all the inclusions have been resolved and the validator has done its job. So you can determine ID attributes. Then you forward events from the new pipeline into the old one. Both the validator in the old pipeline and the validator in the new pipeline correctly sees the whole document. > To find the schema-determined ID, I think I need access to the schema before > the document is validated. Hence, I need to load the schema myself. So, I still fail to understand why you need to load and validate by yourself. I mean, if you think about it, there are million schema languages and million ways to configure each of them. It's just too much for an XInclude processor to handle, don't you think? Oh, I see. Perhaps I now understand your reasoning, are you saying you want the included document to be validated by the same validator that is used to validate the including document (the document that contains inclusion)? If so, is that the right thing to do? I thought XInclude builds an infoset from the included document before you determine which fragment of that document to suck in. The ID-ness of the attribute must have been determined as a part of that process, and if the XML Schema validation is involved in it, that validation must have been done without knowing anything about the including document. If so, it doesn't make sense to me to reuse the validator of the including document. > I'm not sure how to load the scheme. I would prefer to load it in a way > that the subsequent validation can use the pre-load scheme rather than > having to load it all over again. I presume you can copy GrammarPool of the original pipeline into the new pipeline, so that two validators can share the same grammar. regards, -- Kohsuke Kawaguchi Sun Microsystems [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
