Cart
[Home] [By Thread] [By Date] [Recent Entries]
IMO, the non XML format is only a pain for a parser writer. For the author, once learned, I think it easy and comfortable, particularly as I've said before, because one doesn't get lost in element elementness or attribute attributeness. It is easier to think of the element declaration as having a content model that has multiple parts than to wrap oneself around complex and simple types. It's easier to teach too. And yes, not having a lot of primitive types can be an advantage given code that does the post structural validation. Strings are what are wanted if one does not intend to have the parser-centric software do type validation. No, GIs are NOT types anymore than PE names are types. One can use them that way if one chooses, but leave the choice open. I'd drop parameter entities. They tend to obscure the DTD, suggest that it has more semantics than are really there, and end up being a form of documentation implying semantic groups that can be just accidents of structure. len (just another SGML Luddite) From: Dennis Sosnoski [mailto:dms@s...] Simplicity and terseness are at the top of my list. The only real problem with using DTDs now is Namespaces. The non-XML format is a pain, but less so than the verbosity and complexity of Schemas. DTDs are simple enough that they don't really require any special tools, in my experience; Schemas do.
|
