xml-dev - Re: XML Schemas: Best Practices

[Toivo Lainevool <tlainevool@yahoo.com>]

--- "Thomas B. Passin" <tpassin@home.com> wrote:
>  Many principles for OO programming or design are the same
> as for any other software development, and could (should, I
> think) be applied to document or data design too.  Among
> them:
> 
> 1) Minimize interactions between components  (or modules,
> functions, objects, etc.).
> 
> 2) Organize components into well-defined layers to help
> minimize interactions.  The goal is to have components of
> one layer use only components from one other layer wherever
> possible.
> 
> 3) Anticipate what kind of extension might be desired in the
> future,  and provide for it now so that you can extend the
> system with minimal disruption later.
> 
> 4) Adopt a naming convention that helps explain the purpose
> of each component, and use it.
> 
> These lessons (anyone should feel free to add more) have
> been learned the hard way over the years.  Why not take
> advantage of them?
> 
> Cheers,
> 
> Tom Passin
> 
I agree wholeheartedly with this. First I want to expand on a couple of the
points you make above and the apply them to the current Global vs. Local Best
Practices discussion.

Point 1 above refers to "Coupling and Cohesion". Key ideas in OO. Coupling
means to keep dependencies between components at a minimum. Cohesion is how
closely related pieces of a component are to each other. The best way to design
things is to have low coupling and high cohesion[1]. These ideas can also be
expressed by the "Common Closure Principle" and the "Common Reuse
Principle"[2].

Point 3 is an idea that I've seen get abused too often. People seem to like to
design flexibility for the sake of flexibility. A common example is seeing
Design Patterns get overused. Designing extra flexibility into a system causes
it to become overly complex and hard to maintain by anyone except the original
coder. The hard part is identifying the right "hinge points". (The GoF "Design
Pattern" book talks about this but I don't have it handy to provide a
reference.)

Keeping these points in mind, I don't agree with the first general guideline in
the "best Practices" doc[3] which states:
"As a general rule, always start with the Venetian Blind design. This design
provides the most benefits. Its use of types as the primary form of reuse is
consistent with our guidelines in the "type versus element" issue where we
stated, "when in doubt, make it a type". Its ability to turn namespace exposure
on or off with a simple switch gives schemas flexibility and robustness."

This seems to go against point 3, trying to identify flexibility before
identifying a need for it. The Russian Doll design seems to me to have the
highest cohesion and lowest coupling of the three design. For these reasons I
would suggest using the Russian Doll design as a "default", and if there is
some needed extra flexibilty needed (like reusing the pieces outside of the
local scope), then move to the Venitian Blind design.

Thanks,

Toivo Lainevool


[1] See Craig Larman's book "Applying UML and Patterns" where he presents "Low
Coupling" and "High Cohesion" as design patterns.
[2] See Robert C. Martin's "Design Principles and Design Patterns" at:
http://www.objectmentor.com/publications/Principles%20and%20Patterns.PDF
[3] http://www.xfront.com/GlobalVersusLocal.html


__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/