Lists Home |
Date Index |
I think you meant "limits the number of levels of subsections" ... not the
number of subsections.
You can either define
1.a section to be recursive (sections can contain sections at the next
2.a section can contain a subsection which can contain a subsubsection
which can contain a subsubsubsection to whatever level makes sense to your
Which is "better"?
1. infinite section recursion
(dtd/schema)..fairly simple .. one element for any number of levels
(authoring) no limit to depth author can use... no obvious depth
indicator.. everything is a section no matter what level you are at... this
might be a problem in some environments
(publishing)at some level you will hit problems... if each section at a
lower level is indented "x" cm, then clearly you will eventually run off the
page eventually... so you will normally allow for n levels in any of your
code... beyond which something breaks. Usually hard to prevent except by
2. fixed number of named levels
(dtd/schema).. only slightly more complex.. one element per level..
probably each element having the same model
(authoring) .. author knows level in document explicitly by name. The
names you give these structures might be mirrowed by normal use by humans..
so there is no confusion (a legislative problem I worked on, named each
level of text explicitly and legal authors legislators normally referred to
these levels by these names)
(publishing).. layout can be predefined for fixed number of levels
The transformation into html/xhtml is pretty simple for either.
So I guess the answer is ... it depends on your problem.
For the one problem I mentioned above.. it was natural to use the names for
the levels that the people used in day to day activity... and it allowed
tight control of the overall structure. (142 pages into a legal text .. who
can tell what level you are at.. it was nice to know you couldn't go any
more than 8).
If you really need a variable number of levels... then recursive sections
will avoid the "yes I know there are 12 levels allowed... but I need 13 by
tomorrow" problem (except for publishing problem).
W. Hugh Chatfield I.S.P.
CyberSpace Industries 2000 Inc.
XML Consulting & Training
See also: http://www.all-about-perth.com
From: Morcom, Harvey [mailto:Harvey.Morcom@KPMG.co.uk]
Sent: Wednesday, November 20, 2002 9:51 AM
Subject: [xml-dev] DTD Design
We are in the early stages of moving our existing information into XML and I
am starting to look at the DTD and was after some advice.
It was initially proposed that we use the format SubSection(n), however this
limits the number of sub-sections the document can have. I proposed the use
of a generic section element which will remove this. Which approach is
better? What are there strengths/weaknesses? DOCBook which uses nested
section elements states 'Use of deeply nested Sections may cause problems in
some processing systems.' ?
The documents will be displayed via a browser using XSLT to convert the XML
Thanks in advance
This email has been sent from KPMG LLP, a UK limited
liability partnership, or from one of the companies within
its control (which include KPMG Audit Plc , KPMG United
Kingdom Plc and KPMG UK Limited). The information in
this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this
email by anyone else is unauthorised. If you are not the
intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it,
is prohibited and may be unlawful. When addressed to
our clients any opinions or advice contained in this email
are subject to the terms and conditions expressed in the
governing KPMG client engagement letter.
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
- DTD Design
- From: "Morcom, Harvey" <Harvey.Morcom@KPMG.co.uk>