Feh. The article is all about capturing video on a PC with 'Microsoft Windows98/ME/2000/XP'. How about linking to some of the interesting work happening in Linux video capture instead.
I'm not mixing stuff, I asked if binaries compiled for Darwin - which is the BSD core of Mac OS X, and which can be installed by itself on PowerPC boxes - will run under Linux.
FreeBSD on Intel can run binaries compiled for Linux on Intel, so it's not an unreasonable question.
If you did have binary compatibility then you might be able to copy across libraries like Quartz from your Mac OS X partition to your Linux partition. Not much chance I grant you, given that the whole display infrastructure is different, but maybe it could be made to work. If Mac OS X really is built around a BSD core then it wouldn't be too difficult to make it run on top of the Linux kernel interface.
No but booting MacOS over the top of Linux is not the same. Wine lets you run Windows applications without needing the original Windows code, and they execute as Linux processes that happen to have a weird binary loader and set of libraries.
Is there an equivalent of Wine for running Mac OS X applications on Linux/PowerPC? How many of the libraries in Mac OS X have equivalents in Linux (how close is GNUstep to Apple's stuff, etc)?
At the minimum, is it possible to run Darwin/PowerPC binaries on Linux/PowerPC?
This is why you need to be very careful about how you do things in Java applets if you want security. Not really an issue if your code is server side - but in the case of a client side applet - once they have it, they can go through it all easily.
Very true. But in fact, it doesn't just apply to Java. Even in other languages you can disassemble the code and work out what it does. It takes longer than it would to decompile Java bytecode, but it can be done, and if security is important to you then the mere fact that it is 'difficult' to reverse engineer the code shouldn't be enough.
In other words: you cannot trust any code that runs on the client side.
the only spam I get is from Windows e-mail viruses
So these viruses are able to get hold of your email address even though conventional address harvesters cannot. I wonder how long it will be until a spammer creates a virus or worm which as well as mailing itself to everyone in your address book, sends the contents of the address book back to the spammer (by some indirect route). There are probably large numbers of 'lost' addresses which don't appear on the Web but are in somebody's Outlook address book.
Well I don't know about the 'online' part, but certainly the ability to distribute copies of software is a right that you may or may not have.
Similarly, some software gives you the right to modify it (and the source code to do so). Some other software does not give you this right.
You choose what software you want to use based on what rights you consider important, as well as on other factors like price, functionality and support. You may consider a particular right, such as the right to distribute modified versions, to be important even if you don't intend to exercise that right yourself. This is because if other people have that right too, is is more likely that the software will continue to be supported and fixed for security holes even if the vendor goes bust.
Hang on a minute, it looks to me like this new MS licence is in fact a free software licence! Not a very good one but free software nonetheless.
The clauses about not using Microsoft trademarks, marking modified versions as such, and not suing people over software patents are entirely reasonable. Requiring that the user indemnify Microsoft against lawsuits from third parties relating to the user's distribution of the Microsoft code is a bit iffy (RMS says 'requiring indemnities is highly obnoxious') but again, it just has the general aim of avoiding harassment by lawyers and probably isn't that big a deal.
The only unusual clause is the one that says you may not distribute the software 'with other software other software that is licensed under terms that seek to require that the Software (or any intellectual property in it) be provided in source code form, licensed to others to allow the creation or distribution of derivative works, or distributed without charge'. Now does this 'with' refer to derivative works, or does it include mere aggregation?
If the 'with' refers to creating derivative works, then it isn't really any worse than the GNU GPL, which excludes all other licences except itself. It's a bit obnoxious and stupid, sure, but not enough to make the software non-free. After all a strong copyleft licence other than the GPL, call it the Stupid Public Licence or SPL, is considered a free software licence, and it doesn't allow combining with _any_ other software unless it happens to also be SPL-licenced. Microsoft's licence is no worse than the putative SPL.
If the 'with' is attempting to restrict mere aggregation, then it probably is enough to make the software non-free. You could not put Microsoft's code and gcc on the same CD. Interestingly, since it forbids distributing 'with' software whose licence requires it to be 'distributed without charge', you might not be able to put the software on the same CD as other code from Microsoft - since I'm sure that many of their programs like Internet Explorer have terms which say you may distribute, but only without charging a fee.
Microsoft should clarify whether clause 2 in their licence refers to creating derivative works, or attempts to restrict distribution that is even within smelling distance of GPLed code.
No contract will subsist between you and Amazon.co.uk* for the sale by it to you of any product unless and until Amazon.co.uk accepts your order by e-mail confirming that it has dispatched your product.
Exactly. This is not the same as the time they bill you. The price quoted on the web site is an invitation to treat (invitation to enter into a contract); the actual contract is formed when you get the confirmation message.
So if there are some lucky people who ordered the item and got a confirmation message, Amazon is contractually obliged to deliver the goods - whether or not they have yet billed the credit card.
OK, you can parse an existing config file with yacc and lex or bison or Antlr or other parser generators.
But how do you know the grammar? How do you know that the parser you have written will handle all the instances of that file format?
The nice thing about XML is that you can publish a DTD for your file format, and that defines it. Everyone can understand what the DTD means since DTD is itself a standard. (Ditto XML Schema or whatever, although those are a lot more complicated.)
Now, where is the documented grammar for named.conf? Where is the information I need to write a parser for these config files? Nine times out of ten you just have to guess by looking at example files. Manual pages describing the file format are helpful, but they very rarely document everything (for example the page may say 'comments are from # to the end of the line but does not specify what happens when # is inside a string, or when the end of line is escaped with \ ). Even if there is a formal grammar for the file format, it's not likely to be easy to generate a parser from it without some manual work, whereas XML DTD can be used to directly generate a parser with FleXML or other tools.
The point of XML is not that it's technically superior to other file formats but that it is an agreed standard which lots of people understand. This applies also to the grammars for XML files. You can give your file format as a DTD and anyone familiar with DTD can use it, without worrying about side issues like whether \\ inside a single-quoted string becomes one backslash or two. Also there are tools like nsgmls which given a DTD can quickly syntax-check an XML file to see whether it conforms to that DTD. Again, the advantage is in having a common language to talk about file formats, not that XML is magically better than whatever 'Not-Invented-Here' format you might make yourself.
I don't think the namespaces are problematic (you just have to look for/<.+:foo/, right?) but it might be nice for things like processing instructions to be removed, and for comments to disallow the < character. Assuming that the advantage of being able to jump to a random part of the file and quickly find particular elements outweighs the advantage of being able to put unescaped < characters in comments.
Hmm, I ought to have a look at the various XML-lite proposals and see how many of them have this property.
Of course a file cannot be parsed if it has an opening tag that cannot be closed. XML requires all tags to be closed. So the file would not be well-formed XML. I don't see the fact that such a file is not parsable as a problem, as long as the XML parser gives you a meaningful error message ('the tag is opened on line 10 but not closed'), and most do.
You'd only run out of memory if you had an input file that looked like...
for many megabytes. But even that is only allowable if your XML file format (DTD or whatever) permits elements to nest inside other elements. Whether this is true depends on the application. As I mentioned in another post, the same problem applies equally to any language that allows constructs to be nested to arbitrary depth, including C source and Lisp sexps. It's not particularly a limitation of XML.
Yes, it's good that there is a small, easy-to-set-up database that may not have all the features of Oracle or Postgres or DB2, but is good enough for many applications.
What's annoying is that every time MySQL adds some new feature which real RDBMSes have had for a long time, it gets lots of hype and publicity, while free databases which already full ACID properties (I think this means Postgres nowadays, and most likely SapDB too) don't get nearly as much coverage.
Perhaps this is a case of more joy over one sinner who repents, than...
If you are coding against MySQL with Perl it is always just as easy to do
what the trigger or stored procedure will do for you in code in a very short
amount of time.
Stored procedures run inside the database server. This means they can be hella fast (compared to doing the same operations externally by sending SQL and results back and forth). Also the language for stored procedures (Oracle's PL/SQL or Postgres's PGPLSQL or whatever it's called) can be typechecked against the database schema, so you get immediate notification if you try to add a stored procedure that uses invalid column names or whatever. Finally, the code for stored procedures can be compiled just once and then stored as bytecode inside the database.
Really it comes down to: trust the database developers. They have very long, grey beards and they know all sorts of stuff about making things run quickly, so if they have gone to the trouble of implementing a programming language that runs inside the RDBMS you can be pretty sure it will give better performance, and possibly better error reporting, than doing the same job with an external language and a database access library.
What I meant was that Sendmail might use a macro language which is Turing-complete, so you cannot properly parse the files without expanding the macros, and to expand the macros you end up running a whole Turing-complete programming language.
I meant that the *file format* may be a Turing-complete macro system. Obviously a language such as C is Turing-complete, yet its file format is decidable. But there are some languages where the syntax can be changed by executing bits of code at compile time - ie, where there the line between compile time and run time is blurred. Perl is one such language; you cannot in general parse Perl code without also executing some of it. I believe TeX is another. Sendmail's config files might be the same.
But with today's hardware, it's actually quite rare that you will need an 'efficient' file format at all.
Consider how the Unix idea of storing as much as possible in human-readable text files with variable line lengths has displaced binary formats (or fixed-size records) for many applications. Text files are a lot slower to read and less 'scalable' in many ways but so what? Hardware is fast enough.
Of course there are still many cases where you do need to optimize the file format for speed, since as hardware gets faster data sets get (much) bigger. In these cases perhaps an SQL database or a more lightweight database like Berkeley DB would be appropriate. But in most cases, not handcrafting your own binary format.
I'm not particularly proposing storing data as HTML, just saying that you don't need to change the storage format to fix the stupid quoting problems. The fix is simpler than that. Just rip out whatever code currently makes it its business to remove < characters, and replace it with non-broken code that HTML-escapes them properly. Whether this happens on input or output doesn't really matter.
But XPath, at least its implementation in current languages, takes a string as its path. If you specify an element which doesn't exist in the XML then this error will not be caught until run time. Whereas if the compiler knew about the grammar of the XML file it could tell you immediately 'there cannot be a element at this level' or 'no such attribute'. You could even hit Tab in your editor to see what the available subelements are at the current point in the tree.
Also, knowing the grammar (DTD or XML Schema or whatever) of the XML will help generate more efficient code, better than an XPath implementation could be because the general XPath has to work with all possible XML files, not just those restricted to a certain grammar.
It's like the difference between the putative code
int x = a.b[6]->c["hello"];
which is checked at compile time and compiles down into efficient code, and
int x = tree_query("a/b 6/c 'hello");
which walks some data structure at run time. It's better if the language can help you with the data structures.
Well what you propose would work, and may well be the best way to do things (I like the idea of tagging content with its type before storing it, and implemented something similar when I once needed to make a simple message board). But essentially, the change needed is not to do half-baked 'filtering' of text by stripping out 'bad' characters, but just to HTML-escape it correctly, changing & to & and so on. At the moment the Slashdot poster must do this by hand, even for supposedly 'plain text' mode where you shouldn't have to care about HTML.
To reach the Nth entry of an XML file, you've got to read through everything that comes before it.
Hmm, I can see this is a problem. You wouldn't have to fully parse everything that came before but you would have to tokenize at least.
Some kind of extension to XML which let you say 'I expect every 'foo' element to begin at 2000 byte offsets' might partly solve this. It wouldn't make XML suitable as an on-disk format for heavy database apps, but it might help in the middle ground where you want the advantages of XML in parsing and validation, but also want to avoid reading in the whole file for every access. Pad with null bytes between elements and your data will still be a valid XML document.
Alternatively, prohibiting the wacky quoted data sections (the kind that end with ]]!> or something and are hardly ever used), along with making sure that > and < cannot appear unquoted in attribute values (maybe this is already the case), would let you textually scan the file for the string '<foo' to quickly find 'foo' elements. And maybe now I see the point of the original article, that XML cannot be easily scanned with regular expressions. But with a few tweaks perhaps it could be.
But a program to read from XML could also be written to use constant memory, if the XML format does not require arbitrary nesting. For example, if you have the simple DTD
<!ELEMENT people (person*)>
<!ELEMENT person (#PCDATA)>
then files conforming to this DTD will not have nested elements beyond a certain fixed depth (in this case, 2) and so there is a fixed amount of memory which will suffice to parse any file conforming to this DTD.
If you used a different format, one which allowed block structure nested to an arbitrary depth, then as the input files get bigger and bigger they may also get deeper and deeper, so more and more memory is required to keep track of the current depth. But that is a property of the data model, not XML itself. Parsing a pathological C program fragment such as 'if (1) { if (1) { if (1) {...' has the same problem.
The memory required is a property of the data model you use, it doesn't particularly depend on the syntax used to represent that data model, unless you use a deliberately stupid syntax.
I was thinking more from the viewpoint of some person who didn't design the file format of named.conf or whatever, but wants to write his own tool to parse it. If it uses an ad hoc file format he first has to parse that and then do semantic stuff. If it's XML, at least the first stage is already dealt with, and there are fewer things to worry about like 'have I handled nested comments correctly'.
Could you name the 'complex semantics' and 'redundant features' of XML? It seems pretty simple to me. There is a small amount of leftover SGML crud like entities (which probably aren't necessary except to escape the < and > characters), but most of it has been removed.
Anyway, XML doesn't really have semantics, it's just syntax. The closest thing I can think of is the rule that the ordering of attributes in the same element doesn't matter.
Slashdot Mirror
Feh. The article is all about capturing video on a PC with 'Microsoft Windows98/ME/2000/XP'. How about linking to some of the interesting work happening in Linux video capture instead.
I'm not mixing stuff, I asked if binaries compiled for Darwin - which is the BSD core of Mac OS X, and which can be installed by itself on PowerPC boxes - will run under Linux.
FreeBSD on Intel can run binaries compiled for Linux on Intel, so it's not an unreasonable question.
If you did have binary compatibility then you might be able to copy across libraries like Quartz from your Mac OS X partition to your Linux partition. Not much chance I grant you, given that the whole display infrastructure is different, but maybe it could be made to work. If Mac OS X really is built around a BSD core then it wouldn't be too difficult to make it run on top of the Linux kernel interface.
No but booting MacOS over the top of Linux is not the same. Wine lets you run Windows applications without needing the original Windows code, and they execute as Linux processes that happen to have a weird binary loader and set of libraries.
Is there an equivalent of Wine for running Mac OS X applications on Linux/PowerPC? How many of the libraries in Mac OS X have equivalents in Linux (how close is GNUstep to Apple's stuff, etc)?
At the minimum, is it possible to run Darwin/PowerPC binaries on Linux/PowerPC?
Very true. But in fact, it doesn't just apply to Java. Even in other languages you can disassemble the code and work out what it does. It takes longer than it would to decompile Java bytecode, but it can be done, and if security is important to you then the mere fact that it is 'difficult' to reverse engineer the code shouldn't be enough.
In other words: you cannot trust any code that runs on the client side.
So these viruses are able to get hold of your email address even though conventional address harvesters cannot. I wonder how long it will be until a spammer creates a virus or worm which as well as mailing itself to everyone in your address book, sends the contents of the address book back to the spammer (by some indirect route). There are probably large numbers of 'lost' addresses which don't appear on the Web but are in somebody's Outlook address book.
Well I don't know about the 'online' part, but certainly the ability to distribute copies of software is a right that you may or may not have.
Similarly, some software gives you the right to modify it (and the source code to do so). Some other software does not give you this right.
You choose what software you want to use based on what rights you consider important, as well as on other factors like price, functionality and support. You may consider a particular right, such as the right to distribute modified versions, to be important even if you don't intend to exercise that right yourself. This is because if other people have that right too, is is more likely that the software will continue to be supported and fixed for security holes even if the vendor goes bust.
Hang on a minute, it looks to me like this new MS licence is in fact a free software licence! Not a very good one but free software nonetheless.
The clauses about not using Microsoft trademarks, marking modified versions as such, and not suing people over software patents are entirely reasonable. Requiring that the user indemnify Microsoft against lawsuits from third parties relating to the user's distribution of the Microsoft code is a bit iffy (RMS says 'requiring indemnities is highly obnoxious') but again, it just has the general aim of avoiding harassment by lawyers and probably isn't that big a deal.
The only unusual clause is the one that says you may not distribute the software 'with other software other software that is licensed under terms that seek to require that the Software (or any intellectual property in it) be provided in source code form, licensed to others to allow the creation or distribution of derivative works, or distributed without charge'. Now does this 'with' refer to derivative works, or does it include mere aggregation?
If the 'with' refers to creating derivative works, then it isn't really any worse than the GNU GPL, which excludes all other licences except itself.
It's a bit obnoxious and stupid, sure, but not enough to make the software non-free. After all a strong copyleft licence other than the GPL, call it the Stupid Public Licence or SPL, is considered a free software licence, and it doesn't allow combining with _any_ other software unless it happens to also be SPL-licenced. Microsoft's licence is no worse than the putative SPL.
If the 'with' is attempting to restrict mere aggregation, then it probably is enough to make the software non-free. You could not put Microsoft's code and gcc on the same CD. Interestingly, since it forbids distributing 'with' software whose licence requires it to be 'distributed without charge', you might not be able to put the software on the same CD as other code from Microsoft - since I'm sure that many of their programs like Internet Explorer have terms which say you may distribute, but only without charging a fee.
Microsoft should clarify whether clause 2 in their licence refers to creating derivative works, or attempts to restrict distribution that is even within smelling distance of GPLed code.
Exactly. This is not the same as the time they bill you. The price quoted on the web site is an invitation to treat (invitation to enter into a contract); the actual contract is formed when you get the confirmation message.
So if there are some lucky people who ordered the item and got a confirmation message, Amazon is contractually obliged to deliver the goods - whether or not they have yet billed the credit card.
OK, you can parse an existing config file with yacc and lex or bison or Antlr or other parser generators.
But how do you know the grammar? How do you know that the parser you have written will handle all the instances of that file format?
The nice thing about XML is that you can publish a DTD for your file format, and that defines it. Everyone can understand what the DTD means since DTD is itself a standard. (Ditto XML Schema or whatever, although those are a lot more complicated.)
Now, where is the documented grammar for named.conf? Where is the information I need to write a parser for these config files? Nine times out of ten you just have to guess by looking at example files. Manual pages describing the file format are helpful, but they very rarely document everything (for example the page may say 'comments are from # to the end of the line but does not specify what happens when # is inside a string, or when the end of line is escaped with \ ). Even if there is a formal grammar for the file format, it's not likely to be easy to generate a parser from it without some manual work, whereas XML DTD can be used to directly generate a parser with FleXML or other tools.
The point of XML is not that it's technically superior to other file formats but that it is an agreed standard which lots of people understand. This applies also to the grammars for XML files. You can give your file format as a DTD and anyone familiar with DTD can use it, without worrying about side issues like whether \\ inside a single-quoted string becomes one backslash or two. Also there are tools like nsgmls which given a DTD can quickly syntax-check an XML file to see whether it conforms to that DTD. Again, the advantage is in having a common language to talk about file formats, not that XML is magically better than whatever 'Not-Invented-Here' format you might make yourself.
I don't think the namespaces are problematic (you just have to look for /<.+:foo/, right?) but it might be nice for things like processing instructions to be removed, and for comments to disallow the < character. Assuming that the advantage of being able to jump to a random part of the file and quickly find particular elements outweighs the advantage of being able to put unescaped < characters in comments.
Hmm, I ought to have a look at the various XML-lite proposals and see how many of them have this property.
Of course a file cannot be parsed if it has an opening tag that cannot be closed. XML requires all tags to be closed. So the file would not be well-formed XML. I don't see the fact that such a file is not parsable as a problem, as long as the XML parser gives you a meaningful error message ('the tag is opened on line 10 but not closed'), and most do.
...
You'd only run out of memory if you had an input file that looked like
for many megabytes. But even that is only allowable if your XML file format (DTD or whatever) permits elements to nest inside other elements. Whether this is true depends on the application. As I mentioned in another post, the same problem applies equally to any language that allows constructs to be nested to arbitrary depth, including C source and Lisp sexps. It's not particularly a limitation of XML.
Yes, it's good that there is a small, easy-to-set-up database that may not have all the features of Oracle or Postgres or DB2, but is good enough for many applications.
What's annoying is that every time MySQL adds some new feature which real RDBMSes have had for a long time, it gets lots of hype and publicity, while free databases which already full ACID properties (I think this means Postgres nowadays, and most likely SapDB too) don't get nearly as much coverage.
Perhaps this is a case of more joy over one sinner who repents, than...
Stored procedures run inside the database server. This means they can be hella fast (compared to doing the same operations externally by sending SQL and results back and forth). Also the language for stored procedures (Oracle's PL/SQL or Postgres's PGPLSQL or whatever it's called) can be typechecked against the database schema, so you get immediate notification if you try to add a stored procedure that uses invalid column names or whatever. Finally, the code for stored procedures can be compiled just once and then stored as bytecode inside the database.
Really it comes down to: trust the database developers. They have very long, grey beards and they know all sorts of stuff about making things run quickly, so if they have gone to the trouble of implementing a programming language that runs inside the RDBMS you can be pretty sure it will give better performance, and possibly better error reporting, than doing the same job with an external language and a database access library.
MySQL for online shops? Not if you want to take orders online. Atomic transactions would be very advisable for that.
Or does this version of MySQL include InnoDB or whatever other extension you need to get real transactions?
What I meant was that Sendmail might use a macro language which is Turing-complete, so you cannot properly parse the files without expanding the macros, and to expand the macros you end up running a whole Turing-complete programming language.
I meant that the *file format* may be a Turing-complete macro system. Obviously a language such as C is Turing-complete, yet its file format is decidable. But there are some languages where the syntax can be changed by executing bits of code at compile time - ie, where there the line between compile time and run time is blurred. Perl is one such language; you cannot in general parse Perl code without also executing some of it. I believe TeX is another. Sendmail's config files might be the same.
But with today's hardware, it's actually quite rare that you will need an 'efficient' file format at all.
Consider how the Unix idea of storing as much as possible in human-readable text files with variable line lengths has displaced binary formats (or fixed-size records) for many applications. Text files are a lot slower to read and less 'scalable' in many ways but so what? Hardware is fast enough.
Of course there are still many cases where you do need to optimize the file format for speed, since as hardware gets faster data sets get (much) bigger. In these cases perhaps an SQL database or a more lightweight database like Berkeley DB would be appropriate. But in most cases, not handcrafting your own binary format.
I'm not particularly proposing storing data as HTML, just saying that you don't need to change the storage format to fix the stupid quoting problems. The fix is simpler than that. Just rip out whatever code currently makes it its business to remove < characters, and replace it with non-broken code that HTML-escapes them properly. Whether this happens on input or output doesn't really matter.
But XPath, at least its implementation in current languages, takes a string as its path. If you specify an element which doesn't exist in the XML then this error will not be caught until run time. Whereas if the compiler knew about the grammar of the XML file it could tell you immediately 'there cannot be a element at this level' or 'no such attribute'. You could even hit Tab in your editor to see what the available subelements are at the current point in the tree.
Also, knowing the grammar (DTD or XML Schema or whatever) of the XML will help generate more efficient code, better than an XPath implementation could be because the general XPath has to work with all possible XML files, not just those restricted to a certain grammar.
It's like the difference between the putative code
int x = a.b[6]->c["hello"];
which is checked at compile time and compiles down into efficient code, and
int x = tree_query("a/b 6/c 'hello");
which walks some data structure at run time. It's better if the language can help you with the data structures.
Well what you propose would work, and may well be the best way to do things (I like the idea of tagging content with its type before storing it, and implemented something similar when I once needed to make a simple message board). But essentially, the change needed is not to do half-baked 'filtering' of text by stripping out 'bad' characters, but just to HTML-escape it correctly, changing & to & and so on. At the moment the Slashdot poster must do this by hand, even for supposedly 'plain text' mode where you shouldn't have to care about HTML.
Hmm, I can see this is a problem. You wouldn't have to fully parse everything that came before but you would have to tokenize at least.
Some kind of extension to XML which let you say 'I expect every 'foo' element to begin at 2000 byte offsets' might partly solve this. It wouldn't make XML suitable as an on-disk format for heavy database apps, but it might help in the middle ground where you want the advantages of XML in parsing and validation, but also want to avoid reading in the whole file for every access. Pad with null bytes between elements and your data will still be a valid XML document.
Alternatively, prohibiting the wacky quoted data sections (the kind that end with ]]!> or something and are hardly ever used), along with making sure that > and < cannot appear unquoted in attribute values (maybe this is already the case), would let you textually scan the file for the string '<foo' to quickly find 'foo' elements. And maybe now I see the point of the original article, that XML cannot be easily scanned with regular expressions. But with a few tweaks perhaps it could be.
But a program to read from XML could also be written to use constant memory, if the XML format does not require arbitrary nesting. For example, if you have the simple DTD
...' has the same problem.
<!ELEMENT people (person*)>
<!ELEMENT person (#PCDATA)>
then files conforming to this DTD will not have nested elements beyond a certain fixed depth (in this case, 2) and so there is a fixed amount of memory which will suffice to parse any file conforming to this DTD.
If you used a different format, one which allowed block structure nested to an arbitrary depth, then as the input files get bigger and bigger they may also get deeper and deeper, so more and more memory is required to keep track of the current depth. But that is a property of the data model, not XML itself. Parsing a pathological C program fragment such as 'if (1) { if (1) { if (1) {
The memory required is a property of the data model you use, it doesn't particularly depend on the syntax used to represent that data model, unless you use a deliberately stupid syntax.
I was thinking more from the viewpoint of some person who didn't design the file format of named.conf or whatever, but wants to write his own tool to parse it. If it uses an ad hoc file format he first has to parse that and then do semantic stuff. If it's XML, at least the first stage is already dealt with, and there are fewer things to worry about like 'have I handled nested comments correctly'.
I'm curious, what are the ambiguities in the XML specification?
Could you name the 'complex semantics' and 'redundant features' of XML? It seems pretty simple to me. There is a small amount of leftover SGML crud like entities (which probably aren't necessary except to escape the < and > characters), but most of it has been removed.
Anyway, XML doesn't really have semantics, it's just syntax. The closest thing I can think of is the rule that the ordering of attributes in the same element doesn't matter.