RE: [xml-dev] XML information modeling best practices

From
Bill de hÓra <>
To
"'Simon St.Laurent'" <>,
Date
2002-04-29T09:29:54Z
ID
<000c01c1ef60$6c451490$887ba8c0@mitchum>
Thread
RE: [xml-dev] XML information modeling best practices
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> -----Original Message-----
> From: Simon St.Laurent [mailto:]
>

Simon,

XML in the raw is not tool for designing information structures,
that's not its strength. It's best used as a serialization.


> None of these examples prevents developers from doing what 
> they need, at least in so far as their use in the program 
> context for which they were intended.  In the case of 
> Tinderbox, XSLT can extract what I want without any 
> particularly strange trickery, and the program's well worth 
> exploring whatever I think of their XML.

I like the way Jabber and BEEP have utilised XML, JXTA less so. But
line/space oriented (a la python or, hey, a pencil and paper) would
do just as well for _designing_ protocols in.


> I know that information modeling is hard - no question about 
> that.  Is expressing information models in XML really _this_ 
> hard, though?  Or is it just that people don't value taking 
> the effort?

XML's probably the wrong tool for the job.


> The relational database people, whatever their other sins, 
> did an excellent job expressing things like normalization
> approaches.  Object-oriented programming has school after school
> battling 
> out these issues and best to accomplish particular 
> information representations and processing.  XML seems to 
> have left all this to the wind.

XML's not good for thinking about programming. Use as little UML as
possible or sourcecode.

 
> These are kind of Saturday-afternoonish thoughts, but I'm 
> really wondering whether a lot of the confusion around XML 
> (and some of the hideous results we're seeing) comes from a 
> lack of discussion - and tools built around the results of 
> those discussions.

I'd suggest using UML or ER diagrams to design state machines,
processes (lowly parallel) and information structures. Maybe DTDs
for the latter if the data structure is looking like a book or a
syntax tree; IMO DTDs (or even BNF) are easier to follow than
diagrams for recursive or heavily nested structures.  But usually
diagrams are a better medium. 

Bill de hÓra

[A long time ago, in an art college, a well known graphic designer
gives a talk with the final year graphic design students. He asks
everyone what would they want in their studios. Everyone wants
Macs, Photoshop, scanners, cameras, typefaces from German type
designers, repro kit and various must-have-stuff of the day. His
response was, "not one of you said a pencil and paper". He'd done
this at a few colleges; apparently no-one says pencil and paper.]


-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBPM0Sj+aWiFwg2CH4EQKSCwCeOK+KDdfMdUL0pr9tYLw0j66fnGAAoMrq
O5hvHAHUEcveahaaGOCJT/R/
=M6N0
-----END PGP SIGNATURE-----