Lists Home |
Date Index |
Simon St.Laurent <email@example.com> wrote:
> After a week spent wondering why some RDF people seem intent
> on colonizing XML while some relational database people seem
> intent on blasting it as a false god, I've posted a piece
> that takes a brief look at different options for
> representing, storing, and processing information - and come
> to the odd conclusion that they're all useful, if very
> different and not necessarily combinable.
> What we do here is a lot more than "just data".
Indeed. Your 2nd last paragraph:
"I think it's time for developers to take a closer look at how they're
storing data, and what that means for the data and for other developers. We
seem to have moved into an age where modeling information too tightly
against a particular set of processing expectations incurs significant
costs, and it's time to start thinking about what media fits our information
best rather than what we want to do with the information today."
Invokes my response here....
Having spent the better part of a year developing an object relational
mapping partly for the explicit purpose of generating XML I can observe that
getting this right is darn near impossible. I've finally arrived at an
abstract model that I'm comfortable with, but if I unleash it on my
developers it will probably take another year to explain it to them. As
we've worked our way up this learning curve we've instead compromised on a
model that still has a lot of explicitly hard coded assumptions about how
things relate to other things in the three worlds.
I think most people here would agree that mapping a specific domain for a
given "media" (which I read as classes of technologies) is now a fairly well
understood process. We can do it for many media and do any one of them
well. Similarly, we can probably move between mappings in an individual
domain fairly well. The problem comes when attempting to generalize the
solutions across domains and media. As an example; one can fight the old
Computer Science space vs. time optimization issues all over again with push
vs. pull parser models: picking the right optimization is often domain
specific. The more general solution of lazy evaluation results in
requirements for well modeled schema in order to be generally effective and
thus forces the understanding of the domains in a different direction: we no
longer code it in our algorithms but move it into our metadata. All well
and good until we go to move our metadata across media. We've moved the
problem up a layer, but now we've made the solving of the larger problem an
issue of dealing with abstractions that many people can't get their heads
around (although that may ensure employment for some people, I don't think
we can view it as being for the general good).
I could go on about the issues that come about as one attempts to resolve
the issue, but the details are many and perhaps not really relevant. I hold
out some hope for SQL 3 and XQuery to solve some of my particular concerns
in the long run, but the issue of moving metadata and abstract models across
domains and media is going to be with us for a long time yet. I will thus
suggest that what we do here is also a lot more than metadata....