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 tha
t 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 complex
ity, 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.


--
Regards,

Marcus Carr                      email:  mcarr@[...].au
___________________________________________________________________
Allette Systems (Australia)      www:    http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
       - Einstein



-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>