XML MULTI-Fragment Interchange?

[Mark Birbeck]

Bill wrote:
> From: Daniel Veillard <Daniel.Veillard at w3.org>
> > 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 at iedigital.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: q1.xml
Type: application/octet-stream
Size: 1565 bytes
Desc: not available
Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990307/b7dd589d/q1.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: q2.xml
Type: application/octet-stream
Size: 956 bytes
Desc: not available
Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990307/b7dd589d/q2.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: q3.xml
Type: application/octet-stream
Size: 1277 bytes
Desc: not available
Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990307/b7dd589d/q3.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: q4.xml
Type: application/octet-stream
Size: 3920 bytes
Desc: not available
Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990307/b7dd589d/q4.obj