[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XML MULTI-Fragment Interchange?
Bill wrote: > From: Daniel Veillard <Daniel.Veillard@w...> > > Hum, I have been following the streaming/fragment thread. > > However I have the feeling that even multiple fragment body > > extensions would not solve the problem you were facing. If > > I didn't get the discussion wrong, it seems that you rather > > tried to make one very big (i.e. stream) document from > > multiple sources while the scope of the fragment work was > > just the opposite, i.e. how to extract and ship a piece of > > a very big document. > [snip] > And how one might reassemble fragments back into a large > document is another > problem, though the stream should provide sufficient > information to do so. I think Daniel's point is simply that in many situations you may not want to reconstruct the 'large' document. The fragment work seems to relate to providing context to a fragment, such that reasonable work can be done on it. That's not the same - although related - as shipping one great big document in a number of packages. On the theme of multi-fragments, I think the simplest increment from where we are now is to allow for the results set of a query that spans different levels of a tree. I was previously exporting from queries using a simple wrapper, but when I saw the fragment group's work decided to use it with a very slight modification. The change is an obvious one - and I think someone else suggested it on this list the other day - but I wonder if anyone can see any pitfalls. I've enclosed four sets of query results for those who might be interested in approving/criticising my approach. The queries are: http://[server]/documents/ysArticle[author=Ruth] http://[server]/documents/ysArticle[author=Ruth]/ArticleText http://[server]/documents/ysArticle[author=Ruth]/ArticleText/ysText http://[server]/documents/ysArticle[author=Ruth]/ArticleText/ysText[ID=1 ] [Ignore non-quoted stuff, etc., it's still work in progress!] Although the first few actually return pretty much the same information, they differ in where the division between context and requested data is. The first will return all articles by Ruth in their entirety, and so only needs one 'fragbody' element. The second returns the same data, but the articles themselves are now provided only as context, and the containers of the text become the top level of the fragments. This therefore requires two 'fragbody' elements, since there are two articles by Ruth. (Actually it could be one, but because there's an article between the two that is *not* by Ruth, even though it's not getting returned it messes up my merging code!) The third query is not much different from number two, but pushes one more level of data up into the 'context' information. The final query is the one I'm most interested in getting feedback on, in particular on whether I have the context information right. I think the fragment document is a little ambiguous on what level of detail to put in. Some examples in the doc. do what I have done - put in all siblings of any element that is an ancestor of the ones we're interested in - but one of them doesn't. Of course it is partly application-dependent so I'm not that bothered. Comments? Regards, Mark Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 e: Mark.Birbeck@i...
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|