the paper looks interesting. I've looked through the paper. Not very attentive, but reviewing experience have helped to see several issues.
* I'm lost in the details of encoding the structual depth.
* I'm not sure that the size of the result does matter.
The rest of the text is just random notes.
First of all, welcome to the list of Paul:
Reading the long text in a monospace font isn't fun.
It made me laugh:
... Window INI file (btw, correct Window->Windows)
> Yet there is no existing technology to supply a solution to the problem addressed by XString, focusing on the problem of concise and compact XML representation.
I disagree. See the Paul's list.
It a bit nonsense when an XML paper uses the tag name "XML". Such names are not allowed.
> The three child nodes CHILD1, CHILD2, CHILD3 are ...
Actually, the corresponding example has only CHILD1 and CHILD2.
Encoding the depth level leads to the problem. You can't easily copy and paste an XString subtree from one tree to another tree. It contradicts to the statement in the abstract "... allows for easy manipulation and procesing of XML source".
You say that the size reduction is idealistically 50%. Compare it with the naive method. I've taken real-life XML file of 1450210 bytes, compressed it with gzip and get the archive of 374339 bytes, only 1/4 of the original size.
Applying L'Hopital rule for indeterminate ratios is an overkill. And to apply it, you have to give a proof that you can use the rule. A simplier way is to rewrite your expression as
(1 + (1/n)) / (2 + (2/n))
The limit 1/2 is obvious.
Byte/binary representation reminded me LZ compression.
I think the following is a great idea: XML within XML. I recommend you to pay more attention to it and make it one of the main selling points.
How do you think, is it possible to write an XSLT to decode XString representation? If yes, it would be wonderful alternative to disable-output-encoding.
Hope it helps.