Call this Chinese design: no siblings...
Seriously, restrictions on depth in streaming don't mean a ban on the
existence of sibling elements, do they, hence the claim about billion
levels seems a bit off (?)
> the processing cannot utilize data from preceding or following nodes
In many cases, the processing simply doesn't need to use the sibling
data, and that's the beauty of it, isn't it?
Best,
Piotr
On 11/22/2013 11:41 AM, Costello, Roger L. wrote:
Hi Folks,
Consider XSLT code to process a node in the XML tree.
The rules of streaming say that the processing cannot utilize data from
preceding or following nodes. Further, the XSLT code can only access one child
(one downward selection rule).
Given those restrictions, I am led to the following XML design.
For each node:
1. Use lots of attributes. Store in them the data needed for processing the
node.
2. Have one child element only.
So, to enable efficient stream processing, design XML like this:
<root a="..." b="..." c="...">
<node d="..." e="..." f="...">
<node g="..." h="..." i="...">
<node j="..." k="..." l="...">
<node m="..." n="..." o="...">
<node p="..." q="..." r="...">
...
</node>
</node>
</node>
</node>
</node>
</root>
This results in a massively deep tree. For Gigabyte-sized XML files, the
nesting could be a billion levels deep (or more).
Do you agree with this XML design?
/Roger
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--