... What if you have nested elements? Three, four (or more) levels deep?
Whatever the complexity of the language which your application needs, you need to write a program to process it. I don't see how XML changes this. The XML parser which I used once offered automated fetching of XML hunks (a technical term meaning attributes and such, you see how much I know). But I still had to be responsible about testing the values of those hunks, to make sure they fit the context. Using XML does not lift this burden off the programmer's shoulders, as far as I can see.
> Do you really want to
hand your customer some proprietary scheme for how to parse your syntax so they can import your data?
I believe you have to hand them something of your creation which can understand and employ the hunks returned by the XML parser. Whether you call this creation of yours "proprietary" does not seem to me to matter.
> Or would you rather hand them a DTD and let them
use off the shelf parsers and editors?
I do suppose that XML when used with a DTD may well be better than some other language without that additional specification. And XML when used with a DTD may be better than some other language also with a DTD (or some additional specification functionally equivalent to a DTD) -- by virtue of the universality of XML.
My chief doubt concerns all the uses of XML without a DTD, such as for configuration files, and the buildfiles of Ant (as of the last time I looked at Ant).
Also, what about validation? We can run the XML our application spits out against the DTD and validate it for any errors before sending it to the customer.
I guess it is nice that you can validate the XML. But where the XML is used merely to wrap an inner language, then you still have to parse and deal with that inner language. Using XML does not relieve this.
And, if this question as I understand it has merit, then why stop with wrapping your inner language with just one outer language? We could invent a new language, putting tags and elements around all the XML tags and elements. And then you will have to like it -- because you can validate it!
Rich
_______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
