Re: [PLUG] XML, text, and the development of unix

[Adam Turoff <ziggy@panix.com>]

On Tue, Nov 25, 2003 at 11:23:16AM -0500, kmhryhpdblyx@spammotel.com wrote:
> At 11:09 AM 11/25/2003, you wrote:
> >Not quite.  The syntax is only worth so much.  That's like saying
> >once you learn how to use a line-oriented file format that uses # as
> >a comment character, you can understand any config file.
> 
> That's why I said "basic syntax".  It means I don't have to worry about 
> knowing to use tabs instead of spaces for example.

"Basic syntax" in XML is equivalent to "ASCII".  make's use of 
spaces vs. tabs is a semantic issue, not a syntactic one.  A Makefile
that uses spaces to indent the build steps is syntactically valid, but
most likely semantically invalid.

The XML == "The New ASCII" argument is an old one.  It was first put forth 
by Jon Bosak at a conference a few years ago.  *THAT'S* the level at
XML would have to be integrated into the system, for config files, for
files like /etc/passwd and rc.conf, for Makefiles and so on.

> >Learning XML syntax doesn't buy you much.  It doesn't help you debug an
> >XHTML layout, for example.  Knowing how to debug an XHTML layout doesn't
> >help you understand why your Ant script is buggy, or where you XSLT
> >stylesheet bombs out.
> 
> Sorry, I thought we were discussing text config files?  

Jeff's original question was a much bigger scope.

> I look at it this 
> way, it's pretty neat to have the _option_ of creating an XSLT stylesheet 
> for your config file if that's what turns you on.   Then you could display 
> your config file in a browser if you'd like.

Even if all config files were XML, each program would have different
options to configure.  Ergo, a different XML vocabulary in each file.
Ergo, knowing the *semantic* behavior of one config file doesn't help
you too much with the next program's config file.

For example, I can put a LoadModule declaration in my XF86Config in the
right place, but LoadModule is meaningless in my .bashrc.  Both are
using the same syntactic representation -- ASCII.  Converting both to
XML doesn't help me configure X once I have a bunch of bash aliases set
up on my .bashrc.
 
> >Being able to shove all of the "hard problems" to the parser only
> >simplifies one hard problem: syntactic correctness.  Your application
> >will still need to deal with semantic errors, and must do so in a much
> >more complicated manner.
> 
> How so?  I detect the error and handle it in an appropriate manner.  What 
> difference does it make how the file is formatted?

There are *MANY* more ways XML input can fail compared to simple text.
Especially when you're looking at casual manipulation through grep, sed,
awk, head, tail, diff and cut.

> My main point is that I think it's easier for a casual user to understand a 
> well-written XML config file because they don't have to first understand 
> the application-specific syntax of the plain text config file.

I'm happy you think so.  In my experience, casual users find XML files
to be much more stupefying, because it was designed for generic
machine-to-machine interchange, not human readability.  Also, I've found
that most "casual users" can pick up a random plain text config file
pretty intuitively, even if they have never seen the format before -- a
good guess is usually right, espeically if there are contextual clues
from a manpage, or other similar config files.

Config files are not *that* hard to pick up.  Sure, it sucks that
practically every project invents a completely new syntax, but it's not
a big problem.  Shifting everything over to XML makes it a huge problem.

Z.

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug