> Can someone explain how close is DTD to object modelling,
> i.e can I
> consider different DTD's as different objects and combine them to form a
> single document.
In general, no. Each DTD is a bounded system unless designed otherwise.
A DTD can be composed of separate modules which _can_ be combined to make
different variant DTDs (the TEI is a good example) but whole DTDs are the
_result_ of such combinations: they themselves are not objects which can
be combined because -- by definition -- they must describe a single
document type each.
> And how much can we normalise DTD's , for eg I have a system which
> has 'project' as an element and 'task' as an element within it, so I can
> create a DTD like
> <!ELEMENT Project(Task)>
> <!ATTLIST Project code #CDATA #REQUIRED>
> <!ELEMENT Task(Code)>
I think you risk confusing two things here. An attribute on oneelement
type has nothing whatever to do with a subelement of a similar name
lower down the tree. Don't forget XML is case-SENSITIVE :-) You are
<!ELEMENT Project (Task)>
[note the space after the element type name, before the (]. If you
then declare an attribute "code" on that element:
<!ATTLIST Project code CDATA #REQUIRED>
(no # before CDATA), then that requires all occurrences of Project to
have a code attribute, and all occurrences of Project MUST contain
exactly one Task, and each element Task MUST contain exactly one
Code...but you haven't declared what a Code is made up of, and it has
nothing to do with the attribute called "code" two elements earlier.
The confusion may arise from the use of the term "attribute"; the
meaning is different. Let's assume for the moment that Code can
contain just text, (eg <!ELEMENT Code (#PCDATA)>), so in your document
you can now have a structure like this:
See how the Code _element_ you have declared is unrelated to the "code"
attribute. The distinction I try to enforce is that an element is a
container for the text of your document, wherease an attribute is for
information _about_ one of those elements. It's not always possible to
stick to this, but it's a guideline. Don't forget this is markup, not
programming, so concepts like objects and inheritance are things you
or an application does _with_ your text, not an inherent feature of it.
> and so on. But this means that I will have to specify the project
> code at least once to specify the tasks within it, when instead we could
> create another document specifying the project code and task codes
> within it ,and then just mentioning the task code in the main document
> which can identify the project code since task codes are also unique.
I think there is confusion here about how to represent what you want.
You can easily do exactly what you describe using a feature of SGML
called ENTITIES. That's in Lesson 2, though :-)