OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re:DTD Design

[ Lists Home | Date Index | Thread Index ]

[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

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,



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS