Intelligent design is the hypothesis that SOMETHING created all of this.
No it isn't. It says that something has got actively involved after the point of creation to do things that random forces and natural selection can't do.
Finally, Bush does not say that only Intelligent Design should be taught; he advocates for contrasting ideas to be presented to school children on the subject of the origin of species.
They already are. Anyone who learns about evolution is certain to hear about competing ideas and objections to it. What Bush wants is to push specific ideas that match his religious agenda.
"Organs of extreme Perfection and Complication. To suppose that the eye with all its inimitable contrivances for adjusting the focus to different distances, for admitting different amounts of light, and for the correction of spherical and chromatic aberration, could have been formed by natural selection, seems, I freely confess, absurd in the highest degree..."
There are lots of things that seem absurd that are true. For a long time the idea that the Earth went around the sun seemed absurd. It is now well understood how an eye, with all its features, can evolve in very small steps from simple origins (a vaguely light-sensitive patch of skin, for example).
back when this whole thing started, sun was pretty anti-linux
Yes, that explains why, years before SCO started all this, Sun had spent to much time and money working to make Linux one of their main platforms for Java development, why they had opened up Star Office in the form of Open Office, including a version for Linux, why they had been providing an open source version of Sun Studio (NetBeans) for Linux.
Some very strange definition of 'pretty anti-linux', perhaps?
By why let facts get in the way of Slashdot anti-Sun FUD?
On the contrary, it is a very old-fashioned way of doing things. Having your code so strongly tied in to the database tables, as required by Rails, is something most development languages started moving away from in the late 90s.
Older? I started using PHP in 1995, and started using it for everything after its second rewrite in 1997.
When I worked at Sun, the first time we were introduced to Java was in October 1994 when HotJava (the web browser) became stable enough to use. Sun formally announced Java at SunWorld in 1995. I was there. I was also already using PHP at that point.
That was the goal of SGML, and while it didn't succeed as well as it could it did try. XML is what you get when you turn away from that goal in the name of making it negligably easier to parse.
Not according to the initial work on XML of Jon Bosak in the mid 90s, and the text of the proposals to the W3C, and the practical experience of many of us who have used XML since then.
Can be is not will be. Is it, or is this something else you think people who aren't convinced that this is even a good idea whould have to do?
I seem to have difficulty figuring out the point you are trying to make. I'm not saying that anyone will use small libraries such as MiniXML or TinYXML to parse small config files in boot-type situations. I'm not even saying that anyone should use such libraries. What I'm saying is that is that XML could be used in that situation. I'm saying that this is a practical possibility./usr/local/lib/tcl/tcl8.3 is 1.7MB. True, that's no CPAN, and it's mostly character encoding information, but still... there's a lot of trimming to do to match awk.
Of course it is - it is far more than awk - it is a general purpose and flexible language powerful enough for full applications.
If you are really wanting examples of really small boot situations, why even bother with a system big enough to run awk? There are embedded Java systems that run XML parsers to read configuration files that fit within a few 100k of memory!
a JVM + the Java BeanShell script interpreter (143k) combined with nanoXML (30k) are far smaller than a standard Unix kernel + shell + awk.
It certainly is. One of the main design goals was that it should be easily readable and editable by humans. One of the main points of good XML is that meaningful tags should be chosen so that an XML file can be understood without software.
You have posted a total of one message that mentioned a tool that was both native code and may be usable in a native fashion from scripts.
No. I mentioned MiniXML way back. That can be used in just the same way. It is easy to wrap TCL or other scripting languages around such libraries.
No, I was applying additional restrictions on the kind of scripting language I want.
Exactly. However, I may have misunderstood your post as excluding PERL.
Regarding TCL, I think it is still reasonably Small!
and you could fit the interpreter in a "small model" program on Xenix-x86.
That takes me back! I was a Xenix user in the 80s.
Actually, given the age of the universe(latest estimate), and the time at which it takes evolution to work(proven evolution, not spontaneous mutation, a.k.a., magic), it is a mathematical impossibility that humans could have evolved into the advanced state at which they exist given this time frame. There simply isn't enough time for evolution to work.
Saying 'there isn't enough time for evolution to work' given the fossil record which clearly proves in great detail that it certainly has worked is about as crazy as seeing a large building, then stating that it could not have been built, after someone has shown you all the photos of its construction.
[Science starts from the standpoint that everything that can be observed can be explained.]
And who pronounced that everything that can be observed can be explained? Where did this idea come from? Has it been scientifically proven that everything that can be observed can be explained? I must have missed that scientific experiment. Which one was that again?
And who pronounced that some things that can be observed can't be explained? Where did this idea come from? Has it been philosophically or theologically proven that such explanation is impossible? I must have missed that explanation.
It's funny how scientists don't even know where their own unproven dogma begins. But they are quick to make accusations of others.
Its funny how some non-scientists don't want to go beyond where their limited understanding reaches, and are quick to ridicule those who try to understand more.
Duh. The question is HOW did it happen. Those who accept the dogma of evolution often seem use circular logic: it happened, therefore it must have evolved. Quite unscientific thinking.
The question is HOW did it happen. Those who accept creationism/intelligent design often seem to use circular logic: it happened and we don't yet know how, therefore it must have been designed, involving a designer who in turn has to be explained by yet more design. Quite unscientific thinking.
Hardly. Consider the following, slightly unrelated tale. It demonstrates how LITTLE can happen in 13 billion years.
You are completely misunderstanding evolution. It is not random - it merely uses randomness. It involves selection. It has no goals. Your example is random typing events producting "The quick brown fox jumped over the lazy dog's back." This suggests that evolution has to end up with what you ask for. It doesn't. A better example is if you has asked for random typing producing something vaguely like a sentence. That cuts down the odds fantastically! Evolution does not start from scratch each time. It uses what has gone before. If complexity is needed for better survival that can arise very slowly and gradually. So, it is like starting with a jumble of letters a long time ago and gradually changing each one. That further cuts down the odds. Finally, there is selection. Assume that there is some pressure for sentence structure and words. Jumbles of letters which appear more word and sentence-like are reproduced better, the others are scrapped.
Evolution, with its use of existing complexity and selection, means that billions of years is plenty of time for a rich variety of life to have appeared without any designer.
"fluid + heat, yet you get complexity." - A basic Chemical Reaction - The Complexity already exists Yet have you ever witnessed the face of Bill Clinton in your beaker or just 'Random' patterns Your Example is flawed/ Do you have another? (Try Organized Complexed i.e. a recognizable pattern)
The patterns are not necessarily random. Check out the Belousov-Zhabotinsky reaction.
I guess you missed the bit where I was talking about writing the code in awk itself, specifically because awk is eval-safe.
Much of what you were specifying you wanted to do could be done by writing in XML itself (e.g. XSLT) with a single processing tool (such as xsltproc). But, apparently, that was not allowable. Whereas using scripts like awk is.
You know, I have been asking for a pointer to specific tools like this from the very first message in this thread. Why yes, that was my first request, scripting tools for XML. Why has it taken you this long to provide a link (hmmm... actually, you didn't provide a link, but I suppose google will get me what I need)?
Because I have already mentioned so many alternatives! Of course google will get all this! I mentioned that there are very small resource-using C libraries for XML processing. Any one of these can be trivially included in TCL or other scripting languages. I have finally just picked one where someone has done the work for you.
Also, you were using your own selective definition of 'scripting language'. This even excluded PERL. It was hard to figure out what your requirements were.
There are scripting languages with fairly sizable XML libraries that have to be parsed and interpreted every time the script is run. This is unacceptable: too high a startup cost, too many files have to exist and be uncorrupted.
This simply isn't true. For example, tDOM is TCL wrapper around expat, an XML parser written in C. No startup cost, no interpreting.
Install tDOM, and you get exactly what you are implying doesn't exist: the ability to parse XML that is simple, script-based, and fast.
just to provide the capabilities including the ability to write forensic scripts that will work in single-user mode on a minimal system
Use Tcl with tDOM, for example.
External programs don't help, because parsing and dequoting the output of the external program, and making sure you're not subject to eval- or quoting- exploits in the process of doing so, is actually harder than just reading a flat file safely.
awk, sed sort etc. are external programs that need the same checking.
XML is far safer, as it can be quickly checked for validity, unlike a series of arbitrary flat file formats.
[Nonsense. There are plenty of examples in Nature where simple situations give rise to complex results without a designer or without intelligence. I am not trying to be picky, but I hate to see a general statement like that without an example. If there are plenty of examples, then I would be happy to hear about one of them.]
Fair comment. Examples are often found in situations where there are flows of energy in systems far from equilibrium. One of the classic examples is heating a container full of oil from below. After a while regular patterns form on the surface. The situation is simple - fluid + heat, yet you get complexity. Yet more complex is turbulent flow, where energy is being transferred to a liquid by motion. Very complex patters of vortex formation appear, even though the input is simple - fluid + motion. A more visually interesting example are chemical mixtures which can spontaneously develop physical and temporal patterns - regular changes of colour, and moving bands and patterns, all from a simple mixture.
And, of course, there is the Mandelbrot and Julia sets - literally endless complexity can be seen from a very simple iterative process.
And why on earth should there be one? You have to have domain knowledge to parse a file format and do something meaningful with it.
No. You don't have to have have domain knowledge to do this. For example, with XML, you can do things like 'extract the contents of the second element' with any XML file.
I cannot see why XML people find it worth all that trouble. One language for one purpose is fine with me. This applies to make too -- the language fits the purpose of the tool well, and the TAB issue has never gotten in my way during the maybe twelve years I've used it.
How about the reverse view? Why invent a new format for each purpose, requiring specific domain knowledge even to begin to make sense of the file contents?
penalty is this horrible tag soup which is never parseable with standard tools like grep, cat, awk etc.
Having a range of files with tab, or comma, or colon, or other arbitrary delimiters isn't horrible? This is a kind of delimiter-soup which can't be parsed with standard tools unless you already have detailed knowledge of what the delimiter for a file is.
For example, the fact that there's an XML library for C is irrelevant if you don't have a scripting language that's aware of it.
But there are scripting languages that are aware of XML, and there have been for years. TCL, PERL, Python, Ruby etc. There are C programs like xsltproc that can be used from any of these scripting languages in the way that any Unix command can.
If the files in/etc were replaced with XML files, there would be plenty of scripting languages that could pick up and extract information from these files with just a few DOM API calls. (have a look at TclXML or TclDOM, for example).
[You are focussing on what tools you are using to process/etc files]
No shit, sherlock. That is the topic.
No. The topic is "Ant - the Definitive Guide.". Ant is a build tool. A substitute for 'make'. You seemed to want it to be a replacement for 'awk' and 'sort' etc.
I'm asking what the advantage of going to XML for the files in/etc would be. So far it looks like the answer is one of: (a) larger and harder to read and manage bootscripts, (b) having every script load a large XML handling library before doing any work, or (c) redesigning the boot process around a Java VM, to avoid having to reload the VM or *ML handling libraries every time.
You haven't read with I have posted. XML files can be small, and there is no need to load any large XML library (there are libraries that run in a few tens of kilobytes), and you don't need Java - there are tiny XML libraries for C.
What you get are easier to read files (no mess of arbitrary formats) that can have sensible structures and can have their formats extended without breaking existing use.
For a very small system it would have the advantage that you only need one program and one set of libraries to read all configurations.
xsltproc. Tcl XML handling libraries. PERL handling libraries. Java has this built-in.
Awk contains a compact C-styled scripting language that's eval-safe and turing complete. What's the scripting language in XSL?
Almost all XSLT processors allow embedded JavaScript.
If you don't like that, use a DOM API directly in something like TCL or PERL, or even C (or Java).
No thanks. A real scripting language is not an optional feature.
Then use JavaScript rather than the built-in XSTL calling methods etc.
I think we are drifting away from the topic. You are focussing on what tools you are using to process/etc files - I have already shown that XML can be used in small programs and in limited memory and space (such as embedded and boot situations).
I have sort of lost track of what we are debating!
What you're saying is "with XML, you don't need to write a different two-line parser for each file".
Exactly.
What I'm saying is, "with XML, you still have to do something useful with the data". And "doing something useful" involves enough work that the potential savings from the file format are negligable. And "doing something useful" is actually harder with XML because the tools that do said useful stuff don't seem to exist for XML.
They certainly do. However, for better or worse, the tools are written in XML (or, rather, XSLT). There is no need to write a variety of tools when there is a single language that allows all this processing and transforming to be done. The tools to do this are the programs such as xsltproc.
Here is an example like that you gave for awk: You would put something like this into an XSL file:
I showed you an example of parsing/etc/passwd in two lines of awk. Your DTD is going to be longer than that.
You don't need a DTD.
You showed how to parse/etc/passwd. What about all the other formats? Show me a general awk script that will retrieve, say, the value of the second parameter in any file under/etc.
I can show you a Java or C or PERL program that can retrieve the value of the second element in any XML file.
Show me. Show me something that's already hooked into a conventional scripting language (sh, awk, etc) that can be used without major dependencies (so that it can actually be used during boot) and that doesn't involve writing XML to parse XML.
Why should I be limited to 30-year-old scripting languages? What you are asking is to show something already present in decades-old applications for the handling of XML, which was invented in the 90s!
If you want examples of XML being used in very small environments, take a look at the Fusion Real Time Embedded XML SAX Parser, or MiniXML. The latter has no dependences, and allows the loading and searching of XML with just a few lines of C. You don't need to write XML to parse XML - you can use the very simple DOM or SAX apis. The latter would certainly meet your boot time/floppy disc requirement.
Solutions involving Perl or CPAN, or Java, or that are only usable with a webserver installed, will not be considered responsive.
Just because you don't consider them responsive, doesn't mean they aren't. Java and XML are used in real-time device control for example. That is about as responsive as it is possible to get.
No, it doesn't (Thank God!). You're thinking of netbeans.
Why 'thank God'? Why should internal use of Ant be a problem? On the contrary, it has major advantages: It means you can build the project outside of the IDE, and it means that the IDE can make use of just about any Java tool, as almost all of them provide functionality as Ant tasks. Compare this to eclipse, where you need to install plug-ins.
Slashdot Mirror
Intelligent design is the hypothesis that SOMETHING created all of this.
No it isn't. It says that something has got actively involved after the point of creation to do things that random forces and natural selection can't do.
Finally, Bush does not say that only Intelligent Design should be taught; he advocates for contrasting ideas to be presented to school children on the subject of the origin of species.
They already are. Anyone who learns about evolution is certain to hear about competing ideas and objections to it. What Bush wants is to push specific ideas that match his religious agenda.
"Organs of extreme Perfection and Complication. To suppose that the eye with all its inimitable contrivances for adjusting the focus to different distances, for admitting different amounts of light, and for the correction of spherical and chromatic aberration, could have been formed by natural selection, seems, I freely confess, absurd in the highest degree..."
There are lots of things that seem absurd that are true. For a long time the idea that the Earth went around the sun seemed absurd. It is now well understood how an eye, with all its features, can evolve in very small steps from simple origins (a vaguely light-sensitive patch of skin, for example).
back when this whole thing started, sun was pretty anti-linux
Yes, that explains why, years before SCO started all this, Sun had spent to much time and money working to make Linux one of their main platforms for Java development, why they had opened up Star Office in the form of Open Office, including a version for Linux, why they had been providing an open source version of Sun Studio (NetBeans) for Linux.
Some very strange definition of 'pretty anti-linux', perhaps?
By why let facts get in the way of Slashdot anti-Sun FUD?
Yes, RoR is the best thing around
On the contrary, it is a very old-fashioned way of doing things. Having your code so strongly tied in to the database tables, as required by Rails, is something most development languages started moving away from in the late 90s.
RoR is a huge step backwards.
Older? I started using PHP in 1995, and started using it for everything after its second rewrite in 1997.
When I worked at Sun, the first time we were introduced to Java was in October 1994 when HotJava (the web browser) became stable enough to use. Sun formally announced Java at SunWorld in 1995. I was there. I was also already using PHP at that point.
What do you mean by older?
Because Java was developed in 1991.
(I've got to change 8 files or so to add a new field? Java and XML? Puleeeze!)
Haven't you heard of 'refactoring'? Available in all major Java development tools. Adds or changes the field everywhere.
That was the goal of SGML, and while it didn't succeed as well as it could it did try. XML is what you get when you turn away from that goal in the name of making it negligably easier to parse.
/usr/local/lib/tcl/tcl8.3 is 1.7MB. True, that's no CPAN, and it's mostly character encoding information, but still... there's a lot of trimming to do to match awk.
Not according to the initial work on XML of Jon Bosak in the mid 90s, and the text of the proposals to the W3C, and the practical experience of many of us who have used XML since then.
Can be is not will be. Is it, or is this something else you think people who aren't convinced that this is even a good idea whould have to do?
I seem to have difficulty figuring out the point you are trying to make. I'm not saying that anyone will use small libraries such as MiniXML or TinYXML to parse small config files in boot-type situations. I'm not even saying that anyone should use such libraries. What I'm saying is that is that XML could be used in that situation. I'm saying that this is a practical possibility.
Of course it is - it is far more than awk - it is a general purpose and flexible language powerful enough for full applications.
If you are really wanting examples of really small boot situations, why even bother with a system big enough to run awk? There are embedded Java systems that run XML parsers to read configuration files that fit within a few 100k of memory!
a JVM + the Java BeanShell script interpreter (143k) combined with nanoXML (30k) are far smaller than a standard Unix kernel + shell + awk.
XML is not designed to be edited by humans
It certainly is. One of the main design goals was that it should be easily readable and editable by humans. One of the main points of good XML is that meaningful tags should be chosen so that an XML file can be understood without software.
You have posted a total of one message that mentioned a tool that was both native code and may be usable in a native fashion from scripts.
No. I mentioned MiniXML way back. That can be used in just the same way. It is easy to wrap TCL or other scripting languages around such libraries.
No, I was applying additional restrictions on the kind of scripting language I want.
Exactly. However, I may have misunderstood your post as excluding PERL.
Regarding TCL, I think it is still reasonably Small!
and you could fit the interpreter in a "small model" program on Xenix-x86.
That takes me back! I was a Xenix user in the 80s.
Actually, given the age of the universe(latest estimate), and the time at which it takes evolution to work(proven evolution, not spontaneous mutation, a.k.a., magic), it is a mathematical impossibility that humans could have evolved into the advanced state at which they exist given this time frame. There simply isn't enough time for evolution to work.
Saying 'there isn't enough time for evolution to work' given the fossil record which clearly proves in great detail that it certainly has worked is about as crazy as seeing a large building, then stating that it could not have been built, after someone has shown you all the photos of its construction.
[Science starts from the standpoint that everything that can be observed can be explained.]
And who pronounced that everything that can be observed can be explained? Where did this idea come from? Has it been scientifically proven that everything that can be observed can be explained? I must have missed that scientific experiment. Which one was that again?
And who pronounced that some things that can be observed can't be explained? Where did this idea come from? Has it been philosophically or theologically proven that such explanation is impossible? I must have missed that explanation.
It's funny how scientists don't even know where their own unproven dogma begins. But they are quick to make accusations of others.
Its funny how some non-scientists don't want to go beyond where their limited understanding reaches, and are quick to ridicule those who try to understand more.
Duh. The question is HOW did it happen. Those who accept the dogma of evolution often seem use circular logic: it happened, therefore it must have evolved. Quite unscientific thinking.
The question is HOW did it happen. Those who accept creationism/intelligent design often seem to use circular logic: it happened and we don't yet know how, therefore it must have been designed, involving a designer who in turn has to be explained by yet more design. Quite unscientific thinking.
Hardly. Consider the following, slightly unrelated tale. It demonstrates how LITTLE can happen in 13 billion years.
You are completely misunderstanding evolution. It is not random - it merely uses randomness. It involves selection. It has no goals. Your example is random typing events producting "The quick brown fox jumped over the lazy dog's back." This suggests that evolution has to end up with what you ask for. It doesn't. A better example is if you has asked for random typing producing something vaguely like a sentence. That cuts down the odds fantastically! Evolution does not start from scratch each time. It uses what has gone before. If complexity is needed for better survival that can arise very slowly and gradually. So, it is like starting with a jumble of letters a long time ago and gradually changing each one. That further cuts down the odds. Finally, there is selection. Assume that there is some pressure for sentence structure and words. Jumbles of letters which appear more word and sentence-like are reproduced better, the others are scrapped.
Evolution, with its use of existing complexity and selection, means that billions of years is plenty of time for a rich variety of life to have appeared without any designer.
"fluid + heat, yet you get complexity." - A basic Chemical Reaction - The Complexity already exists Yet have you ever witnessed the face of Bill Clinton in your beaker or just 'Random' patterns Your Example is flawed/ Do you have another? (Try Organized Complexed i.e. a recognizable pattern)
The patterns are not necessarily random. Check out the Belousov-Zhabotinsky reaction.
I guess you missed the bit where I was talking about writing the code in awk itself, specifically because awk is eval-safe.
Much of what you were specifying you wanted to do could be done by writing in XML itself (e.g. XSLT) with a single processing tool (such as xsltproc). But, apparently, that was not allowable. Whereas using scripts like awk is.
You know, I have been asking for a pointer to specific tools like this from the very first message in this thread. Why yes, that was my first request, scripting tools for XML. Why has it taken you this long to provide a link (hmmm... actually, you didn't provide a link, but I suppose google will get me what I need)?
Because I have already mentioned so many alternatives! Of course google will get all this! I mentioned that there are very small resource-using C libraries for XML processing. Any one of these can be trivially included in TCL or other scripting languages. I have finally just picked one where someone has done the work for you.
Also, you were using your own selective definition of 'scripting language'. This even excluded PERL. It was hard to figure out what your requirements were.
There are scripting languages with fairly sizable XML libraries that have to be parsed and interpreted every time the script is run. This is unacceptable: too high a startup cost, too many files have to exist and be uncorrupted.
This simply isn't true. For example, tDOM is TCL wrapper around expat, an XML parser written in C. No startup cost, no interpreting.
Install tDOM, and you get exactly what you are implying doesn't exist: the ability to parse XML that is simple, script-based, and fast.
just to provide the capabilities including the ability to write forensic scripts that will work in single-user mode on a minimal system
Use Tcl with tDOM, for example.
External programs don't help, because parsing and dequoting the output of the external program, and making sure you're not subject to eval- or quoting- exploits in the process of doing so, is actually harder than just reading a flat file safely.
awk, sed sort etc. are external programs that need the same checking.
XML is far safer, as it can be quickly checked for validity, unlike a series of arbitrary flat file formats.
[Nonsense. There are plenty of examples in Nature where simple situations give rise to complex results without a designer or without intelligence. I am not trying to be picky, but I hate to see a general statement like that without an example. If there are plenty of examples, then I would be happy to hear about one of them.]
Fair comment. Examples are often found in situations where there are flows of energy in systems far from equilibrium. One of the classic examples is heating a container full of oil from below. After a while regular patterns form on the surface. The situation is simple - fluid + heat, yet you get complexity. Yet more complex is turbulent flow, where energy is being transferred to a liquid by motion. Very complex patters of vortex formation appear, even though the input is simple - fluid + motion. A more visually interesting example are chemical mixtures which can spontaneously develop physical and temporal patterns - regular changes of colour, and moving bands and patterns, all from a simple mixture.
And, of course, there is the Mandelbrot and Julia sets - literally endless complexity can be seen from a very simple iterative process.
You can only create something less perface/Complex than your self.
Nonsense. There are plenty of examples in Nature where simple situations give rise to complex results without a designer or without intelligence.
And why on earth should there be one? You have to have domain knowledge to parse a file format and do something meaningful with it.
No. You don't have to have have domain knowledge to do this. For example, with XML, you can do things like 'extract the contents of the second element' with any XML file.
I cannot see why XML people find it worth all that trouble. One language for one purpose is fine with me. This applies to make too -- the language fits the purpose of the tool well, and the TAB issue has never gotten in my way during the maybe twelve years I've used it.
How about the reverse view? Why invent a new format for each purpose, requiring specific domain knowledge even to begin to make sense of the file contents?
penalty is this horrible tag soup which is never parseable with standard tools like grep, cat, awk etc.
Having a range of files with tab, or comma, or colon, or other arbitrary delimiters isn't horrible? This is a kind of delimiter-soup which can't be parsed with standard tools unless you already have detailed knowledge of what the delimiter for a file is.
For example, the fact that there's an XML library for C is irrelevant if you don't have a scripting language that's aware of it.
/etc were replaced with XML files, there would be plenty of scripting languages that could pick up and extract information from these files with just a few DOM API calls. (have a look at TclXML or TclDOM, for example).
But there are scripting languages that are aware of XML, and there have been for years. TCL, PERL, Python, Ruby etc. There are C programs like xsltproc that can be used from any of these scripting languages in the way that any Unix command can.
If the files in
[You are focussing on what tools you are using to process /etc files]
/etc would be. So far it looks like the answer is one of: (a) larger and harder to read and manage bootscripts, (b) having every script load a large XML handling library before doing any work, or (c) redesigning the boot process around a Java VM, to avoid having to reload the VM or *ML handling libraries every time.
No shit, sherlock. That is the topic.
No. The topic is "Ant - the Definitive Guide.". Ant is a build tool. A substitute for 'make'. You seemed to want it to be a replacement for 'awk' and 'sort' etc.
I'm asking what the advantage of going to XML for the files in
You haven't read with I have posted. XML files can be small, and there is no need to load any large XML library (there are libraries that run in a few tens of kilobytes), and you don't need Java - there are tiny XML libraries for C.
What you get are easier to read files (no mess of arbitrary formats) that can have sensible structures and can have their formats extended without breaking existing use.
For a very small system it would have the advantage that you only need one program and one set of libraries to read all configurations.
OK, show me the tools.
/etc files - I have already shown that XML can be used in small programs and in limited memory and space (such as embedded and boot situations).
xsltproc. Tcl XML handling libraries. PERL handling libraries. Java has this built-in.
Awk contains a compact C-styled scripting language that's eval-safe and turing complete. What's the scripting language in XSL?
Almost all XSLT processors allow embedded JavaScript.
If you don't like that, use a DOM API directly in something like TCL or PERL, or even C (or Java).
No thanks. A real scripting language is not an optional feature.
Then use JavaScript rather than the built-in XSTL calling methods etc.
I think we are drifting away from the topic. You are focussing on what tools you are using to process
I have sort of lost track of what we are debating!
What you're saying is "with XML, you don't need to write a different two-line parser for each file".
Exactly.
What I'm saying is, "with XML, you still have to do something useful with the data". And "doing something useful" involves enough work that the potential savings from the file format are negligable. And "doing something useful" is actually harder with XML because the tools that do said useful stuff don't seem to exist for XML.
They certainly do. However, for better or worse, the tools are written in XML (or, rather, XSLT). There is no need to write a variety of tools when there is a single language that allows all this processing and transforming to be done. The tools to do this are the programs such as xsltproc.
Here is an example like that you gave for awk: You would put something like this into an XSL file:
<xsl:template match="@id > 100">
<xsl:value-of select="@home"/>
</xsl:template>
Then you give this XSL file as a parameter to xsltproc or some equivalent program.
I showed you an example of parsing /etc/passwd in two lines of awk. Your DTD is going to be longer than that.
/etc/passwd. What about all the other formats? Show me a general awk script that will retrieve, say, the value of the second parameter in any file under /etc.
You don't need a DTD.
You showed how to parse
I can show you a Java or C or PERL program that can retrieve the value of the second element in any XML file.
Show me. Show me something that's already hooked into a conventional scripting language (sh, awk, etc) that can be used without major dependencies (so that it can actually be used during boot) and that doesn't involve writing XML to parse XML.
Why should I be limited to 30-year-old scripting languages? What you are asking is to show something already present in decades-old applications for the handling of XML, which was invented in the 90s!
If you want examples of XML being used in very small environments, take a look at the Fusion Real Time Embedded XML SAX Parser, or MiniXML. The latter has no dependences, and allows the loading and searching of XML with just a few lines of C. You don't need to write XML to parse XML - you can use the very simple DOM or SAX apis. The latter would certainly meet your boot time/floppy disc requirement.
Solutions involving Perl or CPAN, or Java, or that are only usable with a webserver installed, will not be considered responsive.
Just because you don't consider them responsive, doesn't mean they aren't. Java and XML are used in real-time device control for example. That is about as responsive as it is possible to get.
[Doesnt eclipse use Ant for its builds? ]
No, it doesn't (Thank God!). You're thinking of netbeans.
Why 'thank God'? Why should internal use of Ant be a problem? On the contrary, it has major advantages: It means you can build the project outside of the IDE, and it means that the IDE can make use of just about any Java tool, as almost all of them provide functionality as Ant tasks. Compare this to eclipse, where you need to install plug-ins.