Cart
[Home] [By Thread] [By Date] [Recent Entries]
Ok, and no disagreement in principle. I've used them myself and given a document that literally has switches in its native structures, found them unavoidable. The topic this impinges on is one of DTD/Schema design where the design is not decoupled from the processes intended to handle instances. Is it really a good idea to design a document type with extra tags whose main job is to make the XSLT simpler to build? *Usually* I've tried to avoid them because they carry no content. They act as process switches. In some cases, one can eliminate them with multiple DTD/Schemas and proper application of namespaces. Sometimes, one discovers the nesting isn't necessary or that the owner of the document is willing to lose them to simplify (the case I remember best is the 38784 tagging). In X3D/VRML, quite a lot of effort was expended over the issues of container tags that existed to satisfy some implementers' requirements for a one pass parse. Eventually, the containers were taken out. Mixed content is a different can of worms. It is a force of nature. One can wall around it, but it introduces more artificiality. Mixed content is a natural part of human documents. It just makes it harder to process. len From: Deborah Aleyne Lapeyre [mailto:dalapeyre@m...] Len said: >Items like not using mixed content >or container elements are *usually* decent advice >in most schema designs. In some schema languages yes, in some no. In specific, containers and mixed content are the real strength of XML in the DTD world. When writing XSLT or quite a few "processing" systems", containers are a godsend.
|
