[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re:DTD Design

• To: xml-dev@l...
• Subject: Re:DTD Design
• From: Sean McGrath <sean.mcgrath@p...>
• Date: Wed, 20 Nov 2002 18:04:26 +0000

[Harvey Morcom]
 >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?

Explicitly named sub-section elements simplify certain types of XML processing
and complicate others.

They simplify various navigation and location operations owing to the explicit
nature of the levelling. However, they complicate generic "section 
handling" owing to
the explicit nature of the levelling. e.g. there are times when you wants 
to say
"sections at any level" and end up having to write "sect1|sect2|...".

Most of the time I opt for a generic recursive levelling construct and utilise
the hierarchical context (ancestors) to deduce levelling depth.

Sometimes however, for human exposure, I use explicit levelling as it
is much easier to visually match up the tags to get your nesting right.
(Very useful for example in legislation example where nesting
can get quite deep.).

Where possible. I cross-translate to explicitly numbered sectioning for
author/edit and cross-translate back to generic recursive for CMS
storage and down-stream processing.

Old-timers on the list will remember the RANK feauture of SGML which
allowed a single element type declaration to infer the creation
of a familiy of numbered elements types. So you could declare
SECT and have tagging for SECT1, SECT2, SECT3 etc.


I hope this helps,


http://seanmcgrath.blogspot.com

• Follow-Ups:
  • Re: Re:DTD Design
    • From: John Cowan <jcowan@r...>

• Prev by Date: unsuscribe
• Next by Date: Re: Universal Applications, Universal Data
• Previous by thread: RE: DTD Design
• Next by thread: Re: Re:DTD Design
• Index(es):
  • Date
  • Thread