> 1. What are the advantages/disadvantages of using the same element name for
> something like a training course and differentiating it with the attribute.
> For example:
> <course type="multimedia"></course> and <course type="leader_led"></course>
> <multimedia_course></multimedia_course> and
This usually depends on how important or easy it is for you to be able to
identify concepts like "all courses, regardless of type" vs how
important or easy it is for the creator of the file (if that's a human)
to have a particular style of interface. Personally I'd always go for
the former method, with attributes, as it tends to be more flexible
(you can add more types more easily). YMMV.
> 2.Is there a mechanism that allows child elements to inherit attributes from
> the parent elements?
That's called an application :-)
Seriously, because XML is not a programming language, all it does is
provide the hooks for an application to implement inheritance. It may
look obvious to a human accustomed to inheritance that
overhead, chalk, etc
means that the requirements element type is "aware" that it is in a
classroom situation, but that actually only happens if the program
which processes the data records "classroom" and makes it available
lower down the tree. Nothing in XML forces the requirements element
type to know anything about classrooms, or even to know that its parent
element type has an attribute called "type". The memory model of a
parsed instance (a "grove" as defined in hyTime and DSSSL) can be used
by communicating processes to pass this kind of information, but
someone still has to cut the code.
Full SGML does provide #CURRENT as an attribute type, meaning "re-use
whatever value was most recently specified earlier for this element type"
(which means the attribute is in effect #required on the first instance
of the element type), but that feature was dropped in XML.