On Mon, 13 Nov 2000, James Duncan Davidson wrote: [del] > I'm open to discussion, of course. So I guess I need to understand why you > want these elements to implement the Element interface... Right now I don't > see the need for the internal model to be a DOM impl where everything is > abstract -- just that the model match up with the external XML > representation on "factual" basis. Data round tripping rather than > byte-to-byte round tripping. I can infer that you would like the DOM for > editing purposes, however DOM elements are abstract and I would think that > as a GUI (and that tasks, etc) would prefer to work strictly with strongly > typed objects. > > Is your concern with keeping comments and such inline with the tasks/targets > they represent? > > If you could give a bit of background, it would help. (And if you have > already explained this once, please forgive. I tried to scan the history of > this list over the last few days, but have probably missed large gaps!)
What is wanted is for the xml file to be modified but to keep the same structure as the user entered (whitespace included). I think what you are proposing is more inline with a Java/XML binding, which I believe is an easier way to manipulate the XML in a java centric. That is compile XML into Java classes. You'll need to work out what is needed and how much of the original XML needs to be kept when working on it. Barrie -- Barrie Treloar ____________________________________________________________________ Barrie Treloar Phone: +61 8 8303 3300 Senior Analyst/Programmer Fax: +61 8 8303 4403 Electronic Commerce Division Email: [EMAIL PROTECTED] Camtech (SA) Pty Ltd http://www.camtech.com.au --- Level 8, 10 Pulteney Street, Adelaide SA 5000, Australia. --- ____________________________________________________________________
