RE: Data design methods? (was Re: APIs, messaging)

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

No, I think the dilemmas are related:

1.  Data design or object-oriented design?

2.  What tool for either?

3.  Are there metrics for good design that the 
    tool enables, enforces, or prevents?

IOW, how many of you think this is good design:

<foo>
  <childrenOfFoo>
    various and sundry foo children

Some will say, "what is that wrapper tag doing 
in there; child nodeness is an XML property not 
needed in the actual instance!"  But for someone 
who wants a context-free parse (What! NO XML PARSE!) 
and sees those various and sundry foo children 
as objects in object oriented fields, well it looks 
just fine.

This isn't easy.  The presence of meta-information 
modelers makes it harder.  It is very hard to model 
above the level of the instance if it is an *instance*. 
It pushes one back to value-pair design and looks a 
lot like... architectural forms.

Len Bullard
Intergraph Public Safety
clbullar@ingr.com
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Michael Champion [mailto:mike.champion@softwareag-usa.com]

>
> The critical question: by what criteria does one choose to create a UML
> description, or an RDF Description, or a Topic Map, or just an XML
> Schema?

I have an even more basic question: by what criteria does one choose between
different DATA designs?  OO methodologies provide criteria for choosing
between
different designs, but as we've brought out here, a good OO design *hides*
data
structures.  Are there widely accepted criteria for defining "good" data
models
independently of the algorithms used to process them?

The only thing that comes to mind that would be relevant to XML is
Entity-Relationship Modelling.  Any thoughts?

I'm aware of David Carlson's website www.xmlmodeling.com (and his recent
book),
but from a quick look it seems to focus on the mechanics of using UML to
model
various XML schemas rather than the "aesthetics" of what a good design looks
like. Am I missing something?