[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Question for updating existing XML file
Michael Kay <michael.h.kay@n...> > > > Probably the greatest weakness of XML as a data model for > > databases is that it > > > doesn't provide a coherent way of modelling the non-hierarchical > > relationships. > > > But that's a weakness of the relational model too. > > > > I'm having a hard time parsing this. Did you perhaps mean > > the inverse; > > that the relational model has a hard time modeling hierarchical > > relationships? Or is this a general comment about the > difficulties in > > modeling for the relational model? If it's the latter I'd disagree; > > just about anyone can at least do a first normal form > model. That may > > not get you real far, but tools abound as do training, books > > and tons of > > best practices to fall back on. > > Well, the relational model has a consistent story on how > relationships are modelled, using primary keys and foreign > keys. It's not a very semantically-rich model, but it's clean > and consistent. Ok, I think I see where you're coming from. I guess I see the extra relational semantics as being via auxiliary type tables. Not codified in the relational model, but a pretty natural result of any (extensive?) normalization? > XML has a clear story on hierarchical relationships, but a > very confused story on those that aren't hierarchical. There > are lots of ways of doing it: URIs, IDREFs, XLinks, or just > "unmarked" foreign keys. None of these is clearly definitive. > Moreover, XML forces you to treat one particular relationship > (the parent-child relationship) very differently from all the > other relationships, so you have to make an early design > decision that won't necessarily be convenient for everyone > for all time. Yes, I've encountered this. It seems to have biased me into a philosophy of avoiding a codification of my XML schema as much as possible; drive the metadata out of the database and produce the schema on demand, after the fact... > There are probably two design decisions in XML that are > really hard to make correctly, yet very hard to change later. > One is "what goes in a document?", the other is "which > relationships should be represented as parent-child > relationships?". One could add a third, elements versus > attributes, but that's fairly trivial in comparison. > Sometimes one can make these decisions instinctively, but > I've come across many cases where the answers are far from > obvious, and there's no discipline akin to relational > normalization that gives you the answer. My approach is to do ER modeling and OO modeling before I attack my XML modeling. That was sort of the rational behind my original question/thesis; I have a vague sort of technique for using ER modeling for XML floating around somewhere in the back of my head (I currently use mostly OO techniques for XML modeling). However, before going there I should observe that doing relationship modeling correctly (whatever correctly may mean) really is _the_ fundamental issue. I'm currently coming down on the MDA side with a model early and model often philosophy.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|