OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: XML Schemas: Best Practices (touches XHTML modularization als o)

I had suggested making substitutionGroups a list of QNames as part of the feedback of the suggestion that became LC-96.  I don't have access to the schema WG's discussions on why an element being a
member of multiple substitution groups was considered undesireable.

If there was some compelling reason that the membership in substitution groups needed to exclusive, then providing open choice groups allows that to remain while providing an extensible content model
for those instances where member elements do not come from a single heirarchy.  If multiple substitution group memberships are allowed and the substitution group examplar has a type urType, then the
two become equivalent and there is no need for open choice groups.

Hard to tell from your description, you might be doing the equivalent of the adapter pattern from the Gang of Four or bring in generic behavior by aggregation instead of inheritance (probably more
likely).  I don't think that your composite elements are substituable any place the more generic components can appear.

If is definitely possible to design a system that uses adapters and aggregation to conform to a strictly single inheritance language.  The convolutions are such that most OOP languages have some sort
of support for one class being substituable for multiple more general bases.  Just try asking a Java developer if he would want to build a complex system using java if he were forbidden to use
"implements".  If is possible, but definitely not desirable.