xml-dev - Re: XML Schemas: Best Practices

["Thomas B. Passin" <tpassin@home.com>]

Toivo Lainevool wrote in part -

> --- "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:
> >
...
> > 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.
> >

> 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 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.)
>
Douglas Bennett in his book "Designing Hard Software" has
drawn an interesting distinction between "use cases" and
"developer cases".  The developer cases cover those things
that the developer (or system designer, or whatever) should
consider but that don't directly relate to user-requested
functionality.  This could include design choices made for
maintainability or expandability reasons.  He advocates
including consideration of the developer cases as much as
use cases during design.

I agree with you about not putting in features like
flexibility where you don't need them.  But ... How many
times do you know that there will be a release two,
three,... and you know something about what would be in
them?  How many times do you know that when you design an
inventory system for one store, pretty soon the customer
will want to add another store?

How often do you expect to create similar systems for
different clients?  Maybe it would be better to create a
framework first.

My point is that you often do have a reasonable idea of
which way a design might go.  Why else would people use
configuration files rather than hard-code in the
configuration values?  And this can be true of document
design as well.  So plan for it to some degree when you can.

Cheers,

Tom Passin