I don't have a good answer for this, but if I had the choice, I'd want both. Reason is simple. Default the XML doc to a specific version, but allow individual elements to be of different version.
In reality, I'd be happy with individual elements containing a version, so I could 'mix-and-match' --- Robert Ollila <[EMAIL PROTECTED]> wrote: > Ned, > > Just one more quick question. When using XSL to translate versions, does > the > versioning information have to be contained in the root node, or can it > be > contained within other elements? The reason I ask is that a single XML > document is composed of many XML elements, each of which may have > versioning > information unique to itself. So, the versioning issue is on an element > basis, rather than just an XML document basis. I suppose XSL can still > work > here, its just that the transformation will have to take place in kind > of a > recursive fashion. Any input, opinions? > > thanks, > > Bob. > > -----Original Message----- > From: Ned Wolpert [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 23, 2002 3:28 PM > To: [EMAIL PROTECTED] > Subject: Re: [castor-dev] using castor for data import from XML into DB > > > On Wed, 2002-01-23 at 10:44, Robert Ollila wrote: > > 1. The object model must be designed in a relational database type of > model > > in order to later use JDO. For example, each class should have some > ID > type > > field, and the cardinality of the relationships may have to be defined > from > > several perspectives within the java classes. In other words, objects > > contained within objects may need to have references to the objects > that > > contain them depending on your database schema. I wouldn't normally > do > this > > if I was not going to use JDO. So, the bottom line is that JDO > support > can > > not just come as an afterthought for ANY object model - the XML schema > you > > use must be designed accordingly. Any input on this ? > > In this specific case I'm not using a legacy database, so I don't have > this specific issue. However, in most of my Java apps, I tend to have an > object model that is different than my database model in some ways. The > mapping file can be easily modified to account for changes in my > database without affecting my object model. However, for this > situation, you have to build the object model based on the database > schema. I don't have a good way to do it that makes it easy to > manipulate on your end. However, the best idea is to take an ER diagram > of your schema, open up and XML schema tool (Like Tibco's) and create > the schema using that technique to compare the two. The best would be to > have a tool to read the database schema and generate an XML schema, but > I know of none that do that. > > (For me, I'd write the XML schema by hand based on database schema, and > manually manipulate it only because I haven't seen a good set of tools > to do this for me.) > > > 2. How do you plan to handle future legacy issues with the data that > is > > produced? For instance, if version 1.0 of your product creates XML > > instances on a users system, what happens when version 2.0 comes out > and > you > > have changed the XML Schema and object model (maybe you added some new > > fields). Will you be able to read the old XML files with the new > object > > model? The same question goes for the database, will you be able to > read > > older objects from the database? I guess this is more of a general > Castor > > issue though. But I am pretty concerned about it. My solution for > now is > > to require that any new fields added to an older schema must be > "optional" > > so that you don't get validation exceptions when you try to unmarshal > an > > older XML instance with the newer java class. That's kind of kludgy > though. > > Any suggestions? > > This has bit me in that past, and will bite me later on, that's for > sure. There are many work-arounds, but no good solution. Some people > attach version numbers to tables/tags. Some provide import tools for > the old database, and XSL/t to translate XML from version 1 to version 2 > (which is what I do) and others just start from scratch and write > adapters each time. (Which is the usual corporate solution I've found in > some companies I worked for) > > For my solution, on the root node of the XML file, keep a version > number. Write style-sheets that can translate from version 1 to version > 2 and use them as a pre-processor routine. If you're database can handle > multiple 'versions' then you're really lucky. Else, you'll have an epoch > event to do an upgrade in your production environment. > > Another possible solution is you leave version 1 the way it is, and > write version 2 to refer to version 1... sorta like OO-style apps, where > you are inheriting from the previous version. Nah... that's too silly. > ;-) > > Let me know what you end up doing. I love these architectural problems. > > -- > > Virtually, > Ned Wolpert <[EMAIL PROTECTED]> > > D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45 > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > ===== Virtually, | "Must you shout too?" Ned Wolpert | -Dante [EMAIL PROTECTED] | _________________/ "Who watches the watchmen?" 4e75 -Juvenal, 120 AD -- Place your commercial here -- fnord __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
