Mike Champion wrote:
> First, doesn't this presuppose a "XML as serialized objects" rather
> than "XML as data liberated from programs and objects" view?
Yes, but you can't ding me for it -- I explicitly stated that that was
the case I was considering :)
I think the valid question here is whether people who are simply using
XML as a way to move their object/database data around should start
thinking in terms of data rather than objects/databases when they design
their XML.
In the short term, I think the answer is that it's a good idea, but not
crucial. In the long term, I think the answer is yes, especially if we
start using XML to expose data to all-comers on the Web in the same way
that we spent the 90's using HTML to share our pets' biographies with
the world.
> Second, does UML allow per se to be modelled effectively?
Got me. I use a paper and pencil.
I use UML as somewhat of a catch-all term to indicate a language that
was designed to model data. The problem with XML schema languages --
even XML Schemas, with all its object-oriented ideas -- is that they
straddle the fence between being syntax-modeling languages and
data-modeling languages.
> 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?
I guess I'm too steeped in the entity-relationship model to be able to
see the difference between objects (entities) and data (stuff that I
group into entities). I suppose you could choose to look at each piece
of data individually, but that's just choosing a different entity size.
> 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.
I suppose it depends on what you mean by "modeling XML". Obviously, any
time you design a document syntax, you are "modeling XML". I was talking
about a somewhat more restrictive usage in which you are designing a
primary model for the data and then asking the question, "When should
you use the XML data model and when should you use another data model,
such as a relational model?"
If XML is not the primary source of the data -- that is, if the data
doesn't "live" in an XML document, but instead just resides in it for
some period of time -- then I don't think you should be thinking in
terms of the XML data model except when designing a serialization
syntax.
Note that that data in business documents like those found in UBL,
RosettaNet, etc. probably doesn't have those documents as a primary
source. That is, those are just serialization formats, albeit long-lived
ones (for historical purposes).
What this means is that I think that in many (most?) cases you'd be
making a mistake if you designed the internals of the applications that
process that business data to use an XML data model. (Yes, I'm sure that
there are good use cases for using the XML data model -- working with
semi-structured data being the best one -- but I think these are
currently in the minority.)
-- Ron
