Saxon

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

I fear you are right: there's a gap here. I propose to fill it by defining the new constructor /** * Create an XdmValue as a sequence of XdmItem objects * @param items a sequence of XdmItem objects. Note that if this is supplied as a list or similar * collection, subsequent changes to the list/collection will have no effect on the XdmValue. */ public XdmValue(Iterable<XdmItem> items) { List values = new ArrayList(); for (XdmItem item : items) { values.add(item.getUnderlyingValue()); } value = new SequenceExtent(values); } which you might care to add to the code yourself as a temporary solution.

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

Thanks ! I'll let you add the code unless I need it sooner. My goal is that I was looking around for a reasonably stable, and ideally "public" and "standard" interface set to use to represent XDM types in my project. I found this sorely lacking out in the field. DOM is reasonably good at nodes, but lacks value types, SAX is good at constructing or deconstructing things but not at actually storing anything, and StAX Events could store things but not high enough level ... no actual fully constructed nodes, and no values. And of course nothing store sequences ... then I stumbled on your new s9api and took a peek and it seems exactly what I was looking for ! So why re-invent it ! (as much as I love to write code, I'm getting older and wiser I hope). Just as I was getting excited, I discovered I cant create everything ... So if you agree that the s9api is a reasonable fit for use for both consumers and producers, it needs public constructors, (or factories) for exposed value types. Could you also make protected XdmNode(NodeInfo node) instead public XdmNode(NodeInfo node) I think that's the other missing piece, otherwise I cannot create a Node value without deriving from XdmNode just to access its constructor. An alternative is a factory and methods for creating these things. Thanks for your help, I really like the s9api, its very clean and seems to do exactly what your design goals were commented, to expose just the right amount of complexity. Now my NEXT task is to be able to be able to PARSE sequences from a Stream but that may be asking too much, as far as I can tell there's no XML standard for a text representation for sequences, although I'd be happy with simply sequences of Nodes (aka an XML document with multiple root nodes). Oh well, I'm sufficing by wrapping everything with a root node. -David Lee

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

>Could you also make protected XdmNode(NodeInfo node) instead public XdmNode(NodeInfo node) Interesting question here as to how much S9API should allow access to the next level down in the stack. Should XdmNode encapsulate NodeInfo and make it completely hidden, or should you allow users to drop a level if they need to? The current design is a little ambiguous in this regard - it allows you to peek inside an XdmNode object to find the NodeInfo, but doesn't allow you to wrap a NodeInfo as an XdmNode. Well, it doesn't explicitly allow it, anyway. I suspect you can do it as XdmNode x = documentBuilder.build(node); provided the documentBuilder isn't set up to do validation or strip whitespace. Which suggests that a more explicit mechanism would do no harm. Michael Kay http://www.saxonica.com/

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

> Which suggests that a more explicit mechanism would do no harm. An alternative which doesnt expose so much SAXON internals (but is a lot more work and a lot more cluttered) is to mirror the classes that create NodeInfo's. If I need to create an XdmNode explicitly, I am (and suggest maybe others) a lot more likely to NOT have NodeInfo at hand but rather a DOM Node or some other API's Node object, so to use XdmNode(NodeInfo node) I'd need to first create that NodeInfo using other saxon classes then pass it to XdmNode ... In some ways it would be cleaner to allow direct creation of XdmNode's directly from all the classes that NodeInfo supports. However, my oppinion is that the current somewhat 'mixed' philosophy is a good compromise. That is, just expose either a factory or constructor based on NodeInfo and let the 'advanced' users dig into other saxon API's to make them. I suspect that the use cases for creating XdmNodes from scratch are a lot fewer and infrequent then the use cases of consuming them so providing a rich set of convenience methods for creating them at the expense of a much more cluttered package is perhaps not a win.

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

If you're starting with say a DOM Node, then you can use documentBuilder.wrap(Node node) to create an XdmNode Michael Kay

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

Thank you ! I looked at that, and it was not at all clear to me that was the way to do it, fantastic. So with the addition of a sequence constructor, I belive the API is complete. Although I do think making the XdmNode(NodeInfo) constructor public would be a very 'nice to have'. Thanks again ! -David