RE: reading from different sources / content navigator

[Alexey Loubyansky <al...@jboss.org>]

Hello Jochen, 

> -----Original Message-----
> From: Jochen Wiedmann [mailto:joe@ispsoft.de] 
> Sent: Wednesday, December 31, 2003 8:42 PM
> To: Alexey Loubyansky
> Cc: jaxme-dev@ws.apache.org
> Subject: Re: reading from different sources / content navigator
>
> > 1. XML schemas.
> > For my case there will be 4: ejb-jar, jboss, jbosscmp-jdbc and the 
> > merged one with redefinitions.
> > I don't modify ejb-jar as it comes from the spec but I do modify 
> > others and so, have to keep the merged one in sync with the 
> changes in 
> > other schemas. That is a problem.
> > XSLT is not an option, as for me, as it is another file to maintain 
> > and that could be even worse than maintaining the merged 
> schema manually.
> > 
> > What are the reasons for the merged schema? I can think of 
> the source 
> > generator. And I don't see another way for generating class 
> hierarchy 
> > from many schemas w/o merging them.
> > Do I need the merged schema on parsing? The documents can 
> be validated 
> > against their own schemas. The generated object factory should also 
> > work fine w/o it. It seems to me, if I provide the class 
> hierarchy and 
> > the factory myself, I could avoid the merged schema.
> 
> I am not sure, what your final target is. I would personally 
> think that you want
> 
>    - manually or automatically create a set of Java beans by 
> merging the
>      above schemata

I am going to do it manually. If one is not going to use a class
generator, I think, there is no need to merge the schemas into one.

>    - have one or three parsers, that take as input such a 
> bean and fill
>      it with information read from these three files

I thought about a parser per file, i.e. in my case three parsers.

>    - while still maintaining upwards compatibility with 
> existing sources

Yes, if it is possible.

> 
> Please correct me if I am wrong. I am viewing our discussion 
> as the most simple and extendible way (in terms of 
> reusability) to achieve the above goals.
> 
> 
> > 4. Object tree merger.
> > Parsing each document will result in a new object tree. We pick the 
> > main one and add the content from the other ones. Visitor 
> pattern fits 
> > nicely here. But it is another, potentially, huge class to maintain.
> > Also, note, object trees the content was merged from become garbage.
> > 
> > I don't like this last one. I like the content navigator much more. 
> > What is wrong with it? I do not implement the SAX parser, I 
> jusr read 
> > the content in memory in the form that can easily be navigated.
> 
> The problem is, that the navigator is much more difficult to 
> integrate in the current framework. The merger fits in very well.

Ok, let's agree on it for now.

Thank you,

Alexey

> 
> Besides, the class wouldn't be quite complex. In contrary, by 
> adding the generator for visitors and a default 
> implementation of the merger to the JaxMe code base, you'd 
> simply have to override certain methods, most probably in the 
> generator.
> 
> 
> Jochen


---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org

Re: reading from different sources / content navigator

[Jochen Wiedmann <jo...@ispsoft.de>]

Alexey Loubyansky wrote:

>>   - manually or automatically create a set of Java beans by 
>>merging the
>>     above schemata
> 
> 
> I am going to do it manually. If one is not going to use a class
> generator, I think, there is no need to merge the schemas into one.

Then lets start with that part. Provide me the Java sources for your
bean classes. I'll provide a schema reader that converts these beans
into a JaxMe parser. (We'll need that anyways, sooner or later.)


Jochen


---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org