"Simon St.Laurent" wrote:
> If I'm actually looking at it, it's not "just" an object serialization.
> A lot of things out there are advertised as using XML for their data
> format, and they do - but then you see things like:
>
> <attrib Name="Text" parent="General"...>
>
> with about 50 of these things, and you know they just dumped an object
> structure into a very loose framework without pausing to consider what
> their information might look like if they brought it to XML directly.
> The object layer may be what they had before, but it leaves a
> translucent goo on the XML.
Ugh. I was missing something. Given the large number of data binding
products out there, I figured that nobody was doing things like that.
This very clearly points out that some people don't understand the
difference between modeling data and modeling the structures that hold
the data. A set of information modeling practices is definitely needed.
> There are two pieces to this puzzle. One is the information, one is the
> representation. Making those two pieces fit together requires an
> understanding of both the information and the representation.
Agreed.
> With XML, I see a lot of conflicting (OOP, RDBMS, LISP, document, EDI)
> cultures smashing heads, and the results are pretty much early
> television.
True, although they'd be better off learning from each other than
smashing heads. Given XML's ability to represent a vast range of data, I
suspect there are few one-size-fits-all solutions.
> The details of broadcasting and license are well
> understood, but the actual programs are of very mixed quality.
As opposed to today -- the mature days of television -- when the actual
programs are not of mixed quality at all, but almost uniformly tripe? ;)
-- Ron
