Saxon

Legacy ID: #6950422 Legacy Poster: Michael Kay (mhkay)

You're certainly right that the code here looks unfinished. It was derived from PullToStax.java, which differs in that a PullProvider offers location information, whereas an EventIterator does not. I suspect I left some code around in anticipation that EventIterator would change some day to offer such information. Have you considered using PullToStax instead? Your code fixes the problem for the simple case where the current PullEvent is a node, but in general I would have thought that's not a very important case. In particular, it will only ever be an attribute, text, comment, or PI node, since elements will have been decomposed into start and end events. (The documentation doesn't clearly say so, but the class is designed to handle decomposed event streams only.) A StartElementEvent contains a locationId, which can be resolved to a real location by using the LocationProvider in the PipelineConfiguration, and I would think this is the right way to provide the information. I'll look into it further. I think that the systemId() on a node should always be an absolute URI - it's designed to reflect the base URI property in the XDM, modulo the impact of the xml:base attribute.

Legacy ID: #6953750 Legacy Poster: Michael Kay (mhkay)

I've committed a patch for this particular case (bug 2711894). In general however, the EventPull pipeline doesn't handle location information particularly well, and I'm finding it difficult to fix this.

Legacy ID: #6955312 Legacy Poster: David Lee (daldei)

Thanks ! I also tried PullToSax and it worked out-of-the box. As to why I didn't try it before ? Well ... its hunt & peck :) (you did ask ... ) Even after working with saxon for > 2 years I still have a difficult time figuring out what classes to use. I know I'm a fairly obscure use case, so I'm not complaining. But frequently I find myself with "Class A" and really need "Class B" so I start hunting for the fragil threads that bind them, hoping such a thing exists. If I'm lucky its 1 or 2 steps removed, but often its 4 or 6 steps removed and I'm just guessing most of the time if its the "right" path to get there. For example this last case you suggested PullToSax which was very useful ... but it still took me quite a while to come up with a working set of transformations. I have a "XdmValue" and need a "XMLStreamReader" ... for the PullToSax case I have found I need to convert XdmValue -> ValueRepresentation -> { Value | NodeInfo } -> SequenceIterator -> PullFromIterator -> PullToStax -> XMLStreamReader And of course I didnt know that chain of transformatoins until I worked backwards and forward to find something that matched ... (and many false starts and dead ends) its definately a deductive reasoning challenge :) But it worked !!!! Although I still dont have a clue if this is the best path between the 2 types (or even a reasonably good path). This sort of problem makes me think there would be a great use for a tool where you could plug in the endpoint types and it would query the codebase/library/type dictionaries and come up with the paths to translate from one type to another. Although I suspect nothing short of AI could really make sense out of anything but the most trivial of translations. Its similar to a proof-generation AI ... Please dont take this as any critisizm of the code, Saxon is an awsome (if complex) codeset and I feel priviledged to work with it.

Legacy ID: #6955646 Legacy Poster: Michael Kay (mhkay)

I can only say that sometimes I forget a class exists too! The PullEvent mechanism was intended as a replacement for PullProvider, but it never quite got far enough to replace all the functionality. Another way of converting from NodeInfo to XMLStreamReader, using rather more "public" interfaces, would be using XQJ: SaxonXQDataSource ds= new SaxonXQDataSource(node.getConfiguration()); XMLStreamReader reader = new SaxonXQItem(node, ds.getConnection()).getItemAsStream()); That does essentially the same as you are doing behind the covers (using PullEvent iterators, and therefore losing the location information). Michael Kay