On Mon, 2002-04-29 at 04:03, Ronald Bourret wrote:
> "Simon St.Laurent" wrote:
> > The XML-based file formats I've
> > looked at lately - the format for Tinderbox, for instance - seem pretty
> > plainly to be raw object serializations without much (any?) thought
> > given to the markup.
>
> Is that such a bad thing? If the XML really is just an object
> serialization, why not just put it out there as such? What sort of
> markup would you consider adding that differed from the canonical object
> serialization?
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.
If you control the entire transaction and don't keep things around for
posterity, fine - do what you want, and maybe XML toolkits will save you
a few hours of coding. If you don't, control everything, it'd be nice
to think about what you're doing.
HTML's limitations forced people to rethink their applications so they
would make sense on the Web. Unfortuantely, XML's capabilities lead a
lot of developers to skip the thinking part.
> 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.
I'll confess that I don't find UML at all useful for data modeling. For
process modeling, it's nice, but the data models I've seem are not
(definitely IMHO) particularly useful. XML is not about computer
programming, and I don't believe that programmer mindsets or tools are
particularly useful for creating XML structures.
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. In this
case, I think it requires an understanding of markup structures to get
it right.
> 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 think you've missed a lot, yes, though it may not actually be a
problem for the particular work you do.
I feel like we're in the early days of television, when there was this
new box with infinite potential and no idea what programming should be.
Ideas from existing media - radio, movies, vaudeville, etc. - weren't
exactly a perfect fit, and it took decdades for programming that medium
to really sort out.
With XML, I see a lot of conflicting (OOP, RDBMS, LISP, document, EDI)
cultures smashing heads, and the results are pretty much early
television. The details of broadcasting and license are well
understood, but the actual programs are of very mixed quality.
Add to that the "private XML (akin to security camera footage?) that
finds its way out into the larger world, and there are some serious
issues with quality to consider.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com
