Hello Oleg:

Thanks for your comments and thoughts. Depending upon if there is a
revision/follow-up to the preview I'll incorporate your feedback.

I did update the web page about XString to include some information
into the overview and discussion of XString.

On 10/7/06, Oleg A. Paraschenko <olpa@x...> wrote:
> Hello William,
>
> 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:
>
> XML Alternatives
> http://pault.com/xmlalternatives.html
>
> ///
>
> Reading the long text in a monospace font isn't fun.
>
> ///
>
> It made me laugh:
>
> ... Window INI file (btw, correct Window->Windows)
> ...
> HOME=/home/jdoe
>
> ///
>
> > 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.
>
>
> --
> Oleg Parashchenko  olpa@ http://xmlhack.ru/  XML news in Russian
> http://uucode.com/blog/  Generative Programming, XML, TeX, Scheme
>