Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Question for updating existing XML file
 Sounds like an excellent paper topic for one of the extreme conferences or a paid-for article at xml.com. I've crunched docs down into relational entities, and yes, it isn't impossible, but it isn't much fun. I'd rather do a straightforward relational design and map out to the document type if I can, keeping the mapping in the SQL and code. Joins don't scare me. :-) Oh... you want this to be a real time dynamic system and not a batch system? len From: Danny Ayers [mailto:danny666@v...] >Peter Hunsberger wrote: > > > >>A more general comment/question: it recently occurred to me that it is >>likely possible to model any XML Schema as a relational schema (proof of >>this theorem is left as an exercise for the reader ;-)? Don't know what >>that gets you, but as I've said at least the tools abound... >> >> Yep. You could do this arbitrarily, by crunching down the schema to its constituent entities and relationships, and building lots of fairly trivial tables to manage them. Perhaps an easier way, for which the tools are already available...wait for it...would be to model the schema in RDF (e.g. using the infoset vocab [1]) , so your inter-element/attribute relationships are expressed as properties, then store the result in a triple-oriented relational store - even just a single table of subject, property, object. > >It often gets you a really bad relational schema. > > Yep. See above. But not necessarily, and bad schemas aren't exactly a novelty using other approaches. >The relational model has a difficult time with things >like recursive elements (think of nested DIVs in HTML). >Element types with lots of optional attributes and repeatable >subelements get hairy when translated the relational model. >Mixed content is problematic too. > >Another exercise for the reader: try modeling something >simple like HTML 2.0 (or for the really adventurous, something >more complex like DocBook) as a relational database. >It's probably doable, but I doubt you'd really want >to work with any database that was structured that way. > > As I'm fresh from some pleasantly satisfying RDF-in-RDBMS play, I've no qualms about suggesting a core model of triples (to provide the most granular relationships) mapped to SQL VIEWs of the business domain, though preferably spread over several tables to sensibly manage resources and literals. Optimisations can be made schema-specific, e.g. tables where you've got a group of elements as peers. (Whether you'd actually want to do this with such doc-oriented vocabs is another matter, might be a fun approach for journalists wishing to shuffle and republish their stories). Having said that, rather than mapping over the XML structure and bringing in possibly irrelevant structural artifacts, you could simple refactor your XML to follow one of the varieties of RDF/XML syntax. Either way, your application (in the general case) can look at structures closer to the domain model than either DOM/XPath hierachies or the SQL version of the relational model - thanks to the graph. Depending on the app, it might well be possible to leverage a lot more of the relational set/logic capability, a la Datalog etc. What fragmenting the XML schema down to such a level of granularity does get you is the potential for interop, it's easier to match simpler structures. This may be at the cost of performance in the first instance, but at least it can be done, and optimizations could follow. 'Course this is something not altogether lost on the RDF'ers, especially if you throw in a bit of ontological magic to manage the vocabularies. Cheers, Danny. [1] http://www.w3.org/TR/xml-infoset-rdfs -- Raw http://dannyayers.com 
|
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
|
|||||||||
