[
Lists Home |
Date Index |
Thread Index
]
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@mulberrytech.com]
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.
|
