Robert Ollila 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? > Well since you can obtain a DocumentHandler from the Unmarshaller you should be able to easily integrate your own XSLT processor with only a few lines of code. However I was thinking, since Castor already comes with our XSLT processor that we could hook it up by default...if we see a <?xsl:stylesheet ?> processing instruction we could automatically process the XML before unmarshalling. We would obviously make the option of which XSLT processor to use up to the user, we could even resort to using JAXP if we had to. I have other issues on my plate right now, but maybe I can hack something up over the weekend. Thanks, --Keith > -----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 ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
