Lists Home |
Date Index |
Eric Bohlman wrote:
> OTOH, that kind of grouping makes it easier (and less error-prone) to
> implement a change affecting all of a set of elements; you only need to
> change the content model or attribute list in one place, without the risk
> of missing one.
That assumes that you do want to make the change to the whole set - I've sometimes found that when I've
started modifying the content model of a set of elements that I don't actually want to make the change
to all of the elements in the set, so I'll pop some elements out and make them a new set of them. By
the end of the process, I might have a couple of smaller sets and who knows what else. I don't find
that sets necessarily lead to tidiness or maintainability.
Also, I tend to organise element declarations alphabetically in DTDs of any size and complexity, so
that probably biases me away from groups too. I agree that groups could be helpful to some, but
personally I haven't used them for a long time and don't miss them.
Marcus Carr email: firstname.lastname@example.org
Allette Systems (Australia) www: http://www.allette.com.au
"Everything should be made as simple as possible, but not simpler."