4/29/2002 4:03:13 AM, Ronald Bourret <> wrote:
>
>Put another way, for a lot of information modeling, it seems that you
>should be modeling in a format such as UML which can then be translated
>to a number of formats, one of them (of course) being XML.
>
>The main exception to this is when you are storing data in an XML
>database. That is, when your data model is the XML data model. In this
>case, it seems entirely appropriate to start with XML.
>
>Or am I missing something here altogether?
I wouldn't say you're missing something, but it raises a few questions.
First, doesn't this presuppose a "XML as serialized objects" rather
than "XML as data liberated from programs and objects" view?
Second, does UML allow per se to be modelled effectively? Maybe
I haven't dug into it deeply enough, but I get the impression it wants
to want to encapsulate data in objects rather than model data in its
own right. For that matter, is UML a reasonable tool for modelling
RDBMS tables, which are clearly data in their own right?
Finally, isn't the case where you want to model XML considerably more
general than "when you are storing data in an XML database"? Whenever
the XML document/message will have some identity and persistence in its
own right -- such as one of the business documents modelled by
UBL, RosettaNet, OAGI -- it's probably worth modelling as XML
data rather than an object, I'd guess. What I don't know is whether
"data" is just an object with nothing but getter/setter methods, for
the purposes of modelling. I'd guess not: XML has it's own rather
idiosyncratic (but useful) notions of what an "entity" is (in the
modelling sense, notthe XML sense -- I'm thinking of elements vs
attributes), and various ways of dealing with relationships, with
a strong bias towards "IS-A" or "is part of" and other hierarchical
relationships.
I definitely agree that this is a deep, and largely unexplored topic
that needs a lot of thought, research, experimentation, etc.
