Re: Should Inline be private in the private part of a package spec?

[Shark8 <onewingedshark@gmail.com>]

On Tuesday, August 14, 2012 9:11:56 AM UTC-6, Georg Bauhaus wrote:
> 
> Or, in other words, if programmers use XML as if it was
> like program source text, XML turns out to be very different.

Who said anything about source-text? The problem with XML, besides parsing, is that it really does tend to spin out of control when you're using it.

One of my college group-projects was a virtual notebook [using SVG wrapped in XML for the 'pages'], written in Java. We were working with person/module style and I had the save/load module; I got it all coded up and my module was working pretty nicely but for some reason when we tried to integrate it into the program it suddenly wasn't working. Turns out the namespace attribute had to be set. That's right the presence/absence of that single [optional, according to the documentation, IIRC] attribute caused the whole thing to fail.

> Wow. At least witty commentary compensates for the lack
> of understanding of the basics of XML.

What's there to understand when you're evaluating it as a container?
Take config-files, they're usually much better stored in an INI file.
About the only thing I can really envision XML being appropriate for, and this is likely a stretch, would be serialization of [OOP]  objects where the tag would be either an object or a primitive type, a primitive type being self-closing and having a value attribute where the object-tag would enclose tags corresponding to its own fields (either object-tags or primitive-tags themselves)... of course that pretty much just described the text-format DFM files Delphi uses (which I like more because of their readability and philosophy of "if it's the default, don't save it" which is sadly missing from a lot of config/state/obj serializations).

> 
> XML is not intended to be readable in the sense that Ada
> was intended to be readable.

Yes, it was; both were meant to be human readable.
Though if you meant the emphasis of readability was not the same I would agree: XML is skewed toward the machine away from the human, at least in use.

> Readable in the case of XML
> means something more plain, something more technical:
> that anyone can read XML documents using a pair of
> eyes and a program like "more". No knowledge of any other
> language is required, no knowledge of bit patterns is required.

And that's where XML often fails. Sure you "can*, as in might be able to, operate an XML file with a plain-text viewer -- but again, once there's any real-life complexity, then the relevant information [the signal] is quickly lost in a sea of noise.

This is why INI files beat XML as config files: there is so little noise built into the format of "sections containing key/value pairs."

> Nor is XML intended for internal data formats.

That doesn't stop people from doing so; I've seen it in web-programs and desktop apps (a lot more now that MS-Office's *.???x format is widespread).