Lists Home |
Date Index |
- From: Avneet Sawhney <firstname.lastname@example.org>
- To: email@example.com
- Date: Thu, 21 Jan 1999 17:57:58 -0500
The more I look into it, I don't see DTD's as an efficient way to
support inheritance. The use of internal subsets seems just a
workaround. The use of parameter entities and the INCLUDE and IGNORE
statements require too much collaboration between the interested
parties. I guess you could make every element and attribute an entity,
but that does not seem appropriate. Also, as stated, inheritance at more
than one level is especially difficult.
For instance, how would I implement the following type of an N-deep
object for a memo:
Let's say a memo is maintained as an industry standard DTD of (header,
body, trailer), each of these having their own subelements.
Now, an individual firm will use this DTD, but wants to simply extend
the header element for internal needs, and reuse the other subelements
without having to redefine those.
Then, a department within that firm wants to tack on its own attributes
to one of the header elements, again, reusing the base definition, and
not having to redefine it as part of an entity.
This can continue to a group within the dept., and finally to the
application in that group which actually uses the memo.
This kind of structure would allow the flexibility for changes at the
company or department level without the normal dependencies.
Without the use of namespaces, simply redefining the elements as is
supported now is not appropriate because of the possible name clashing.
Is namespaces the answer, or is the "extends" feature from DCD's what I
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)