XML-related processors

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

XML-related processors

christian.ohr

Hi Martin,

I added XSD validation support last week, and I'm currently working on Schematron validation (which is needed for validating CDA documents against e.g. the CCD profile, which comes with predefined Schematron rules). Schematron validation basically is a series of Xslt transformations, scanning the final result for error reports.
The processors take a slightly different approach than the corresponding Camel endpoints (e.g. some caching, dynamic selection of stylesheet/schema, etc.)

All of these XML processors (XSD, Xslt, Schematron) are not CDA-specific. Except for their DSL extension part they also don't depend on Camel.
I don't want to bloat commons-core, so would a new commons-xml project be an appropriate location? Should the DSL extensions remain in platform-camel-core (as opposed to something like platform-camel-xml)?

cu
Christian

Christian Ohr | Software Architect | R&D ProfessionalGate
InterComponentWare AG | Industriestraße 41 | 69190 Walldorf (Baden) | Germany
Tel.: +49 (0) 6227 385 152 | Fax: +49 (0) 6227 385 491
[hidden email] |
www.icw.de| www.lifesensor.com


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ICW und GE Healthcare starten strategische Partnerschaft. Anspruch
beider Unternehmen ist, weltweit anstehende Transformationsprozesse
in nationalen Gesundheitswesen mit flexiblen und interoperablen
IT-Lösungen zu unterstützen:
www.icw.de/presse
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *




[hidden email] wrote on 11.07.2009 11:29:36:

> [image removed]

>
> Re: [Ipf-user] Camel 2.x

>
> Martin Krasser

>
> to:

>
> ipf-user

>
> 11.07.2009 11:29

>
> Sent by:

>
> [hidden email]

>
> Please respond to ipf-user

>

> Vesto, Guy (GE Healthcare) schrieb:
> > Regarding your second question. We do have a need for Java5 support for
> > some legacy product bundling of IPF.  
> > I assume IPF 1.7-M1 requires JDK6 - correct?
> >  
> Yes, IPF 1.7-m1 requires Java 6. Can you please open a feature request
> in our issue tracker for supporting Java 5?
>
> Thanks,
> Martin
> > Thanks,
> > - Guy Vesto
> >
> > -----Original Message-----
> > From: [hidden email]
> > [
[hidden email]] On Behalf Of Hadrian
> > Zbarcea
> > Sent: Friday, July 10, 2009 9:27 AM
> > To: [hidden email]
> > Subject: Re: [Ipf-user] Camel 2.x
> >
> > I still plan to help with this.
> >
> > As you all know by now camel-2.0-m2 is out.  However I did not start on
> > the ipf migration to 2.0 yet.  One of the main reasons are that actually
> > camel-2.0.0 is planned to be released really soon now, we hope this
> > month.  The other, more important one is that there are few api changes
> > from 20-m2 to 2.0, most notably the disappearance of all the
> > DefaultExchange specialization and changes in the Exchange api I will
> > implement in the next few days (see the heated discussions on dev@, on
> > which we hope you to participate btw :)).
> >
> > So I have a few questions now.
> > 1.  Do you want a intermediate migration to 2.0-m2, although another
> > migration to 2.0 will be necessary?
> > 2.  Do you want to support java5 (camel does) or you don't really care
> > about that.
> >
> > Thanks
> > Hadrian
> >
> >
> > On May 28, 2009, at 2:07 AM, Martin Krasser wrote:
> >
> >  
> >> Hadrian,
> >>
> >> Great news! We highly welcome your help, thanks a lot! I just created
> >> a Wiki page, with some initial entries related to IPF 2.0 and a Camel
> >> 2.0 upgrade. Lets extend it as we go along. This page can also be used
> >>    
> >
> >  
> >> to collect further community feedback about what should go into IPF
> >> 2.0 (section 'wishlist').
> >>
> >>
http://repo.openehealth.org/confluence/display/ipf/IPF+2.0
> >>
> >> There will be an experimental 2.0 branch available as soon as
> >> IPF-1.7-m1
> >> is out.
> >>
> >> Cheers,
> >> Martin
> >>
> >> Hadrian Zbarcea schrieb:
> >>    
> >>> If you want, I can help with that.
> >>> Hadrian
> >>>
> >>> On May 27, 2009, at 3:51 PM, Martin Krasser wrote:
> >>>
> >>>
> >>>      
> >>>> Italo Giovani Stefani schrieb:
> >>>>
> >>>>        
> >>>>> I know the IPF 1.6 works fine for Camel .16.
> >>>>>
> >>>>> I need to use Camel 2.0. Is there a dead line to launch a Camel 2.0
> >>>>>          
> >
> >  
> >>>>> compatible version?
> >>>>>
> >>>>>
> >>>>>          
> >>>> Right now we didn't start to upgrade IPF to use Camel 2.0. The main
> >>>> reason is that Camel 2 is not backwards compatible to Camel 1. There
> >>>>        
> >
> >  
> >>>> are many API changes. At the moment I cannot estimate the effort and
> >>>>        
> >
> >  
> >>>> the issues for such an upgrade. I plan to create an experimental IPF
> >>>>        
> >
> >  
> >>>> branch (using Camel 2.0) in Q3/2009 and hope to have a first
> >>>> milestone release ready early Q4/2009.
> >>>>
> >>>> Hope that helps,
> >>>> Martin
> >>>>
> >>>>        
> >>>>> Regards
> >>>>>
> >>>>> Italo Giovani Stefani
> >>>>> Vetta Technologies -
www.vettatech.com<http://www.vettatech.com/>
> >>>>> TEL +55 31 4062-7227 ext 5045 FAX +55 31 4062-7227 ext 6002
> >>>>>
> >>>>>
> >>>>>
> >>>>> -------------------------------------------------------------------
> >>>>> -----
> >>>>>
> >>>>> _______________________________________________
> >>>>> Ipf-user mailing list
> >>>>> [hidden email]
> >>>>>
http://gforge.openehealth.org/mailman/listinfo/ipf-user
> >>>>>
> >>>>>
> >>>>>          
> >>>> _______________________________________________
> >>>> Ipf-user mailing list
> >>>> [hidden email]
> >>>>
http://gforge.openehealth.org/mailman/listinfo/ipf-user
> >>>>
> >>>>        
> >>> _______________________________________________
> >>> Ipf-user mailing list
> >>> [hidden email]
> >>>
http://gforge.openehealth.org/mailman/listinfo/ipf-user
> >>>
> >>>
> >>>      
> >> _______________________________________________
> >> Ipf-user mailing list
> >> [hidden email]
> >>
http://gforge.openehealth.org/mailman/listinfo/ipf-user
> >>    
> >
> > _______________________________________________
> > Ipf-user mailing list
> > [hidden email]
> >
http://gforge.openehealth.org/mailman/listinfo/ipf-user
> >
> > _______________________________________________
> > Ipf-user mailing list
> > [hidden email]
> >
http://gforge.openehealth.org/mailman/listinfo/ipf-user
> >
> >  
>
> _______________________________________________
> Ipf-user mailing list
> [hidden email]
>
http://gforge.openehealth.org/mailman/listinfo/ipf-user
InterComponentWare AG:
Vorstand: Peter Reuschel (Vors.), Norbert Olsacher / Aufsichtsratsvors.: Prof. Dr. Christof Hettich
Firmensitz: 69190 Walldorf, Industriestraße 41 / AG Mannheim HRB 351761 / USt.-IdNr.: DE 198388516

_______________________________________________
Ipf-developer mailing list
[hidden email]
http://gforge.openehealth.org/mailman/listinfo/ipf-developer
Reply | Threaded
Open this post in threaded view
|

Re: XML-related processors

mrt1nz
Administrator
Christian,

a common-xml sounds good to me. I'd also prefer to have the DSL
extensions in platform-camel-core. Pairings such as
- commons-core - platform-camel-core
- commons-xml - platform-camel-xml
- ...
only make sense if we plan to support other integration frameworks than
Camel in the future. This was our initial plan but I'd rather like to
drop that for IPF 2.0. I think it make sense to merge these pairs in
most of the cases and only provide additional components if they really
common to most/all other components. Not sure if commons-xml will be
merged with others in the future but we definitly shouldn't create an
additional platform-camel-xml. See also:

http://repo.openehealth.org/confluence/display/ipf/IPF+2.0#IPF2.0-FurtherIPF2.0considerations

Cheers,
Martin

[hidden email] schrieb:

>
> Hi Martin,
>
> I added XSD validation support last week, and I'm currently working on
> Schematron validation (which is needed for validating CDA documents
> against e.g. the CCD profile, which comes with predefined Schematron
> rules). Schematron validation basically is a series of Xslt
> transformations, scanning the final result for error reports.
> The processors take a slightly different approach than the
> corresponding Camel endpoints (e.g. some caching, dynamic selection of
> stylesheet/schema, etc.)
>
> All of these XML processors (XSD, Xslt, Schematron) are not
> CDA-specific. Except for their DSL extension part they also don't
> depend on Camel.
> I don't want to bloat commons-core, so would a new commons-xml project
> be an appropriate location? Should the DSL extensions remain in
> platform-camel-core (as opposed to something like platform-camel-xml)?
>
> cu
> Christian
>
> Christian Ohr | Software Architect | R&D ProfessionalGate
> InterComponentWare AG | Industriestraße 41 | 69190 Walldorf (Baden) |
> Germany
> Tel.: +49 (0) 6227 385 152 | Fax: +49 (0) 6227 385 491
> [hidden email] | www.icw.de| www.lifesensor.com
>
>
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> ICW und GE Healthcare starten strategische Partnerschaft. Anspruch
> beider Unternehmen ist, weltweit anstehende Transformationsprozesse
> in nationalen Gesundheitswesen mit flexiblen und interoperablen
> IT-Lösungen zu unterstützen: www.icw.de/presse
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>
>
>
>
> [hidden email] wrote on 11.07.2009 11:29:36:
>
> > [image removed]
> >
> > Re: [Ipf-user] Camel 2.x
> >
> > Martin Krasser
> >
> > to:
> >
> > ipf-user
> >
> > 11.07.2009 11:29
> >
> > Sent by:
> >
> > [hidden email]
> >
> > Please respond to ipf-user
> >
> > Vesto, Guy (GE Healthcare) schrieb:
> > > Regarding your second question. We do have a need for Java5
> support for
> > > some legacy product bundling of IPF.  
> > > I assume IPF 1.7-M1 requires JDK6 - correct?
> > >  
> > Yes, IPF 1.7-m1 requires Java 6. Can you please open a feature request
> > in our issue tracker for supporting Java 5?
> >
> > Thanks,
> > Martin
> > > Thanks,
> > > - Guy Vesto
> > >
> > > -----Original Message-----
> > > From: [hidden email]
> > > [mailto:[hidden email]] On Behalf Of Hadrian
> > > Zbarcea
> > > Sent: Friday, July 10, 2009 9:27 AM
> > > To: [hidden email]
> > > Subject: Re: [Ipf-user] Camel 2.x
> > >
> > > I still plan to help with this.
> > >
> > > As you all know by now camel-2.0-m2 is out.  However I did not
> start on
> > > the ipf migration to 2.0 yet.  One of the main reasons are that
> actually
> > > camel-2.0.0 is planned to be released really soon now, we hope this
> > > month.  The other, more important one is that there are few api
> changes
> > > from 20-m2 to 2.0, most notably the disappearance of all the
> > > DefaultExchange specialization and changes in the Exchange api I will
> > > implement in the next few days (see the heated discussions on dev@, on
> > > which we hope you to participate btw :)).
> > >
> > > So I have a few questions now.
> > > 1.  Do you want a intermediate migration to 2.0-m2, although another
> > > migration to 2.0 will be necessary?
> > > 2.  Do you want to support java5 (camel does) or you don't really care
> > > about that.
> > >
> > > Thanks
> > > Hadrian
> > >
> > >
> > > On May 28, 2009, at 2:07 AM, Martin Krasser wrote:
> > >
> > >  
> > >> Hadrian,
> > >>
> > >> Great news! We highly welcome your help, thanks a lot! I just
> created
> > >> a Wiki page, with some initial entries related to IPF 2.0 and a
> Camel
> > >> 2.0 upgrade. Lets extend it as we go along. This page can also be
> used
> > >>    
> > >
> > >  
> > >> to collect further community feedback about what should go into IPF
> > >> 2.0 (section 'wishlist').
> > >>
> > >> http://repo.openehealth.org/confluence/display/ipf/IPF+2.0
> > >>
> > >> There will be an experimental 2.0 branch available as soon as
> > >> IPF-1.7-m1
> > >> is out.
> > >>
> > >> Cheers,
> > >> Martin
> > >>
> > >> Hadrian Zbarcea schrieb:
> > >>    
> > >>> If you want, I can help with that.
> > >>> Hadrian
> > >>>
> > >>> On May 27, 2009, at 3:51 PM, Martin Krasser wrote:
> > >>>
> > >>>
> > >>>      
> > >>>> Italo Giovani Stefani schrieb:
> > >>>>
> > >>>>        
> > >>>>> I know the IPF 1.6 works fine for Camel .16.
> > >>>>>
> > >>>>> I need to use Camel 2.0. Is there a dead line to launch a
> Camel 2.0
> > >>>>>          
> > >
> > >  
> > >>>>> compatible version?
> > >>>>>
> > >>>>>
> > >>>>>          
> > >>>> Right now we didn't start to upgrade IPF to use Camel 2.0. The
> main
> > >>>> reason is that Camel 2 is not backwards compatible to Camel 1.
> There
> > >>>>        
> > >
> > >  
> > >>>> are many API changes. At the moment I cannot estimate the
> effort and
> > >>>>        
> > >
> > >  
> > >>>> the issues for such an upgrade. I plan to create an
> experimental IPF
> > >>>>        
> > >
> > >  
> > >>>> branch (using Camel 2.0) in Q3/2009 and hope to have a first
> > >>>> milestone release ready early Q4/2009.
> > >>>>
> > >>>> Hope that helps,
> > >>>> Martin
> > >>>>
> > >>>>        
> > >>>>> Regards
> > >>>>>
> > >>>>> Italo Giovani Stefani
> > >>>>> Vetta Technologies - www.vettatech.com<http://www.vettatech.com/>
> > >>>>> TEL +55 31 4062-7227 ext 5045 FAX +55 31 4062-7227 ext 6002
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> -------------------------------------------------------------------
> > >>>>> -----
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> Ipf-user mailing list
> > >>>>> [hidden email]
> > >>>>> http://gforge.openehealth.org/mailman/listinfo/ipf-user
> > >>>>>
> > >>>>>
> > >>>>>          
> > >>>> _______________________________________________
> > >>>> Ipf-user mailing list
> > >>>> [hidden email]
> > >>>> http://gforge.openehealth.org/mailman/listinfo/ipf-user
> > >>>>
> > >>>>        
> > >>> _______________________________________________
> > >>> Ipf-user mailing list
> > >>> [hidden email]
> > >>> http://gforge.openehealth.org/mailman/listinfo/ipf-user
> > >>>
> > >>>
> > >>>      
> > >> _______________________________________________
> > >> Ipf-user mailing list
> > >> [hidden email]
> > >> http://gforge.openehealth.org/mailman/listinfo/ipf-user
> > >>    
> > >
> > > _______________________________________________
> > > Ipf-user mailing list
> > > [hidden email]
> > > http://gforge.openehealth.org/mailman/listinfo/ipf-user
> > >
> > > _______________________________________________
> > > Ipf-user mailing list
> > > [hidden email]
> > > http://gforge.openehealth.org/mailman/listinfo/ipf-user
> > >
> > >  
> >
> > _______________________________________________
> > Ipf-user mailing list
> > [hidden email]
> > http://gforge.openehealth.org/mailman/listinfo/ipf-user
> InterComponentWare AG:
> Vorstand: Peter Reuschel (Vors.), Norbert Olsacher /
> Aufsichtsratsvors.: Prof. Dr. Christof Hettich
> Firmensitz: 69190 Walldorf, Industriestraße 41 / AG Mannheim HRB
> 351761 / USt.-IdNr.: DE 198388516
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ipf-developer mailing list
> [hidden email]
> http://gforge.openehealth.org/mailman/listinfo/ipf-developer
>  

_______________________________________________
Ipf-developer mailing list
[hidden email]
http://gforge.openehealth.org/mailman/listinfo/ipf-developer
Reply | Threaded
Open this post in threaded view
|

Re: XML-related processors

christian.ohr

Agreed.
I think, we should keep the strict separation between platform (=Camel)-dependent stuff and the independent stuff (commons-*, modules-*) .
I'll create a commons-xml and only put the processors into platform-camel-core

christian

Christian Ohr | Software Architect | R&D ProfessionalGate
InterComponentWare AG | Industriestraße 41 | 69190 Walldorf (Baden) | Germany
Tel.: +49 (0) 6227 385 152 | Fax: +49 (0) 6227 385 491
[hidden email] |
www.icw.de| www.lifesensor.com


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ICW und GE Healthcare starten strategische Partnerschaft. Anspruch
beider Unternehmen ist, weltweit anstehende Transformationsprozesse
in nationalen Gesundheitswesen mit flexiblen und interoperablen
IT-Lösungen zu unterstützen:
www.icw.de/presse
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *




[hidden email] wrote on 13.07.2009 09:38:19:

> [image removed]

>
> Re: [Ipf-developer] XML-related processors

>
> Martin Krasser

>
> to:

>
> ipf-developer

>
> 13.07.2009 09:38

>
> Sent by:

>
> [hidden email]

>
> Please respond to ipf-developer

>

> Christian,
>
> a common-xml sounds good to me. I'd also prefer to have the DSL
> extensions in platform-camel-core. Pairings such as
> - commons-core - platform-camel-core
> - commons-xml - platform-camel-xml
> - ...
> only make sense if we plan to support other integration frameworks than
> Camel in the future. This was our initial plan but I'd rather like to
> drop that for IPF 2.0. I think it make sense to merge these pairs in
> most of the cases and only provide additional components if they really
> common to most/all other components. Not sure if commons-xml will be
> merged with others in the future but we definitly shouldn't create an
> additional platform-camel-xml. See also:
>
>
http://repo.openehealth.org/confluence/display/ipf/IPF+2.0#IPF2.0-
> FurtherIPF2.0considerations
>
> Cheers,
> Martin
>
> [hidden email] schrieb:
> >
> > Hi Martin,
> >
> > I added XSD validation support last week, and I'm currently working on
> > Schematron validation (which is needed for validating CDA documents
> > against e.g. the CCD profile, which comes with predefined Schematron
> > rules). Schematron validation basically is a series of Xslt
> > transformations, scanning the final result for error reports.
> > The processors take a slightly different approach than the
> > corresponding Camel endpoints (e.g. some caching, dynamic selection of
> > stylesheet/schema, etc.)
> >
> > All of these XML processors (XSD, Xslt, Schematron) are not
> > CDA-specific. Except for their DSL extension part they also don't
> > depend on Camel.
> > I don't want to bloat commons-core, so would a new commons-xml project
> > be an appropriate location? Should the DSL extensions remain in
> > platform-camel-core (as opposed to something like platform-camel-xml)?
> >
> > cu
> > Christian
> >
> > Christian Ohr | Software Architect | R&D ProfessionalGate
> > InterComponentWare AG | Industriestraße 41 | 69190 Walldorf (Baden) |
> > Germany
> > Tel.: +49 (0) 6227 385 152 | Fax: +49 (0) 6227 385 491
> > [hidden email] |
<a href=www.icw.de|>www.icw.de|www.lifesensor.com
> >
> >
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> > ICW und GE Healthcare starten strategische Partnerschaft. Anspruch
> > beider Unternehmen ist, weltweit anstehende Transformationsprozesse
> > in nationalen Gesundheitswesen mit flexiblen und interoperablen
> > IT-Lösungen zu unterstützen:
www.icw.de/presse
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> >
> >
> >
> >
> > [hidden email] wrote on 11.07.2009 11:29:36:
> >
> > > [image removed]
> > >
> > > Re: [Ipf-user] Camel 2.x
> > >
> > > Martin Krasser
> > >
> > > to:
> > >
> > > ipf-user
> > >
> > > 11.07.2009 11:29
> > >
> > > Sent by:
> > >
> > > [hidden email]
> > >
> > > Please respond to ipf-user
> > >
> > > Vesto, Guy (GE Healthcare) schrieb:
> > > > Regarding your second question. We do have a need for Java5
> > support for
> > > > some legacy product bundling of IPF.  
> > > > I assume IPF 1.7-M1 requires JDK6 - correct?
> > > >  
> > > Yes, IPF 1.7-m1 requires Java 6. Can you please open a feature request
> > > in our issue tracker for supporting Java 5?
> > >
> > > Thanks,
> > > Martin
> > > > Thanks,
> > > > - Guy Vesto
> > > >
> > > > -----Original Message-----
> > > > From: [hidden email]
> > > > [
[hidden email]] On Behalf Of Hadrian
> > > > Zbarcea
> > > > Sent: Friday, July 10, 2009 9:27 AM
> > > > To: [hidden email]
> > > > Subject: Re: [Ipf-user] Camel 2.x
> > > >
> > > > I still plan to help with this.
> > > >
> > > > As you all know by now camel-2.0-m2 is out.  However I did not
> > start on
> > > > the ipf migration to 2.0 yet.  One of the main reasons are that
> > actually
> > > > camel-2.0.0 is planned to be released really soon now, we hope this
> > > > month.  The other, more important one is that there are few api
> > changes
> > > > from 20-m2 to 2.0, most notably the disappearance of all the
> > > > DefaultExchange specialization and changes in the Exchange api I will
> > > > implement in the next few days (see the heated discussions on dev@, on
> > > > which we hope you to participate btw :)).
> > > >
> > > > So I have a few questions now.
> > > > 1.  Do you want a intermediate migration to 2.0-m2, although another
> > > > migration to 2.0 will be necessary?
> > > > 2.  Do you want to support java5 (camel does) or you don't really care
> > > > about that.
> > > >
> > > > Thanks
> > > > Hadrian
> > > >
> > > >
> > > > On May 28, 2009, at 2:07 AM, Martin Krasser wrote:
> > > >
> > > >  
> > > >> Hadrian,
> > > >>
> > > >> Great news! We highly welcome your help, thanks a lot! I just
> > created
> > > >> a Wiki page, with some initial entries related to IPF 2.0 and a
> > Camel
> > > >> 2.0 upgrade. Lets extend it as we go along. This page can also be
> > used
> > > >>    
> > > >
> > > >  
> > > >> to collect further community feedback about what should go into IPF
> > > >> 2.0 (section 'wishlist').
> > > >>
> > > >>
http://repo.openehealth.org/confluence/display/ipf/IPF+2.0
> > > >>
> > > >> There will be an experimental 2.0 branch available as soon as
> > > >> IPF-1.7-m1
> > > >> is out.
> > > >>
> > > >> Cheers,
> > > >> Martin
> > > >>
> > > >> Hadrian Zbarcea schrieb:
> > > >>    
> > > >>> If you want, I can help with that.
> > > >>> Hadrian
> > > >>>
> > > >>> On May 27, 2009, at 3:51 PM, Martin Krasser wrote:
> > > >>>
> > > >>>
> > > >>>      
> > > >>>> Italo Giovani Stefani schrieb:
> > > >>>>
> > > >>>>        
> > > >>>>> I know the IPF 1.6 works fine for Camel .16.
> > > >>>>>
> > > >>>>> I need to use Camel 2.0. Is there a dead line to launch a
> > Camel 2.0
> > > >>>>>          
> > > >
> > > >  
> > > >>>>> compatible version?
> > > >>>>>
> > > >>>>>
> > > >>>>>          
> > > >>>> Right now we didn't start to upgrade IPF to use Camel 2.0. The
> > main
> > > >>>> reason is that Camel 2 is not backwards compatible to Camel 1.
> > There
> > > >>>>        
> > > >
> > > >  
> > > >>>> are many API changes. At the moment I cannot estimate the
> > effort and
> > > >>>>        
> > > >
> > > >  
> > > >>>> the issues for such an upgrade. I plan to create an
> > experimental IPF
> > > >>>>        
> > > >
> > > >  
> > > >>>> branch (using Camel 2.0) in Q3/2009 and hope to have a first
> > > >>>> milestone release ready early Q4/2009.
> > > >>>>
> > > >>>> Hope that helps,
> > > >>>> Martin
> > > >>>>
> > > >>>>        
> > > >>>>> Regards
> > > >>>>>
> > > >>>>> Italo Giovani Stefani
> > > >>>>> Vetta Technologies -
www.vettatech.com<http://www.vettatech.com/>
> > > >>>>> TEL +55 31 4062-7227 ext 5045 FAX +55 31 4062-7227 ext 6002
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > -------------------------------------------------------------------
> > > >>>>> -----
> > > >>>>>
> > > >>>>> _______________________________________________
> > > >>>>> Ipf-user mailing list
> > > >>>>> [hidden email]
> > > >>>>>
http://gforge.openehealth.org/mailman/listinfo/ipf-user
> > > >>>>>
> > > >>>>>
> > > >>>>>          
> > > >>>> _______________________________________________
> > > >>>> Ipf-user mailing list
> > > >>>> [hidden email]
> > > >>>>
http://gforge.openehealth.org/mailman/listinfo/ipf-user
> > > >>>>
> > > >>>>        
> > > >>> _______________________________________________
> > > >>> Ipf-user mailing list
> > > >>> [hidden email]
> > > >>>
http://gforge.openehealth.org/mailman/listinfo/ipf-user
> > > >>>
> > > >>>
> > > >>>      
> > > >> _______________________________________________
> > > >> Ipf-user mailing list
> > > >> [hidden email]
> > > >>
http://gforge.openehealth.org/mailman/listinfo/ipf-user
> > > >>    
> > > >
> > > > _______________________________________________
> > > > Ipf-user mailing list
> > > > [hidden email]
> > > >
http://gforge.openehealth.org/mailman/listinfo/ipf-user
> > > >
> > > > _______________________________________________
> > > > Ipf-user mailing list
> > > > [hidden email]
> > > >
http://gforge.openehealth.org/mailman/listinfo/ipf-user
> > > >
> > > >  
> > >
> > > _______________________________________________
> > > Ipf-user mailing list
> > > [hidden email]
> > >
http://gforge.openehealth.org/mailman/listinfo/ipf-user
> > InterComponentWare AG:
> > Vorstand: Peter Reuschel (Vors.), Norbert Olsacher /
> > Aufsichtsratsvors.: Prof. Dr. Christof Hettich
> > Firmensitz: 69190 Walldorf, Industriestraße 41 / AG Mannheim HRB
> > 351761 / USt.-IdNr.: DE 198388516
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Ipf-developer mailing list
> > [hidden email]
> >
http://gforge.openehealth.org/mailman/listinfo/ipf-developer
> >  
>
> _______________________________________________
> Ipf-developer mailing list
> [hidden email]
>
http://gforge.openehealth.org/mailman/listinfo/ipf-developer
InterComponentWare AG:
Vorstand: Peter Reuschel (Vors.), Norbert Olsacher / Aufsichtsratsvors.: Prof. Dr. Christof Hettich
Firmensitz: 69190 Walldorf, Industriestraße 41 / AG Mannheim HRB 351761 / USt.-IdNr.: DE 198388516

_______________________________________________
Ipf-developer mailing list
[hidden email]
http://gforge.openehealth.org/mailman/listinfo/ipf-developer
Reply | Threaded
Open this post in threaded view
|

Re: XML-related processors

mrt1nz
Administrator
[hidden email] schrieb:
>
> Agreed.
> I think, we should keep the strict separation between platform
> (=Camel)-dependent stuff and the independent stuff (commons-*,
> modules-*) .
Where do you see the advantage? Since we're only using it in context of
the Camel-specific components, there no reuse. Right now, we use the
components always pairwise.We might reuse it somewhere else in the
future ... do we have a use case?

> I'll create a commons-xml and only put the processors into
> platform-camel-core
>
> christian
>
> Christian Ohr | Software Architect | R&D ProfessionalGate
> InterComponentWare AG | Industriestraße 41 | 69190 Walldorf (Baden) |
> Germany
> Tel.: +49 (0) 6227 385 152 | Fax: +49 (0) 6227 385 491
> [hidden email] | www.icw.de| www.lifesensor.com
>
>
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> ICW und GE Healthcare starten strategische Partnerschaft. Anspruch
> beider Unternehmen ist, weltweit anstehende Transformationsprozesse
> in nationalen Gesundheitswesen mit flexiblen und interoperablen
> IT-Lösungen zu unterstützen: www.icw.de/presse
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>
>
>
>
> [hidden email] wrote on 13.07.2009 09:38:19:
>
> > [image removed]
> >
> > Re: [Ipf-developer] XML-related processors
> >
> > Martin Krasser
> >
> > to:
> >
> > ipf-developer
> >
> > 13.07.2009 09:38
> >
> > Sent by:
> >
> > [hidden email]
> >
> > Please respond to ipf-developer
> >
> > Christian,
> >
> > a common-xml sounds good to me. I'd also prefer to have the DSL
> > extensions in platform-camel-core. Pairings such as
> > - commons-core - platform-camel-core
> > - commons-xml - platform-camel-xml
> > - ...
> > only make sense if we plan to support other integration frameworks than
> > Camel in the future. This was our initial plan but I'd rather like to
> > drop that for IPF 2.0. I think it make sense to merge these pairs in
> > most of the cases and only provide additional components if they really
> > common to most/all other components. Not sure if commons-xml will be
> > merged with others in the future but we definitly shouldn't create an
> > additional platform-camel-xml. See also:
> >
> > http://repo.openehealth.org/confluence/display/ipf/IPF+2.0#IPF2.0-
> > FurtherIPF2.0considerations
> >
> > Cheers,
> > Martin
> >
> > [hidden email] schrieb:
> > >
> > > Hi Martin,
> > >
> > > I added XSD validation support last week, and I'm currently
> working on
> > > Schematron validation (which is needed for validating CDA documents
> > > against e.g. the CCD profile, which comes with predefined Schematron
> > > rules). Schematron validation basically is a series of Xslt
> > > transformations, scanning the final result for error reports.
> > > The processors take a slightly different approach than the
> > > corresponding Camel endpoints (e.g. some caching, dynamic
> selection of
> > > stylesheet/schema, etc.)
> > >
> > > All of these XML processors (XSD, Xslt, Schematron) are not
> > > CDA-specific. Except for their DSL extension part they also don't
> > > depend on Camel.
> > > I don't want to bloat commons-core, so would a new commons-xml
> project
> > > be an appropriate location? Should the DSL extensions remain in
> > > platform-camel-core (as opposed to something like platform-camel-xml)?
> > >
> > > cu
> > > Christian
> > >
> > > Christian Ohr | Software Architect | R&D ProfessionalGate
> > > InterComponentWare AG | Industriestraße 41 | 69190 Walldorf (Baden) |
> > > Germany
> > > Tel.: +49 (0) 6227 385 152 | Fax: +49 (0) 6227 385 491
> > > [hidden email] | www.icw.de| <www.icw.de%7C>www.lifesensor.com
> > >
> > >
> > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * * *
> > > ICW und GE Healthcare starten strategische Partnerschaft. Anspruch
> > > beider Unternehmen ist, weltweit anstehende Transformationsprozesse
> > > in nationalen Gesundheitswesen mit flexiblen und interoperablen
> > > IT-Lösungen zu unterstützen: www.icw.de/presse
> > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * * *
> > >
> > >
> > >
> > >
> > > [hidden email] wrote on 11.07.2009 11:29:36:
> > >
> > > > [image removed]
> > > >
> > > > Re: [Ipf-user] Camel 2.x
> > > >
> > > > Martin Krasser
> > > >
> > > > to:
> > > >
> > > > ipf-user
> > > >
> > > > 11.07.2009 11:29
> > > >
> > > > Sent by:
> > > >
> > > > [hidden email]
> > > >
> > > > Please respond to ipf-user
> > > >
> > > > Vesto, Guy (GE Healthcare) schrieb:
> > > > > Regarding your second question. We do have a need for Java5
> > > support for
> > > > > some legacy product bundling of IPF.  
> > > > > I assume IPF 1.7-M1 requires JDK6 - correct?
> > > > >  
> > > > Yes, IPF 1.7-m1 requires Java 6. Can you please open a feature
> request
> > > > in our issue tracker for supporting Java 5?
> > > >
> > > > Thanks,
> > > > Martin
> > > > > Thanks,
> > > > > - Guy Vesto
> > > > >
> > > > > -----Original Message-----
> > > > > From: [hidden email]
> > > > > [mailto:[hidden email]] On Behalf Of
> Hadrian
> > > > > Zbarcea
> > > > > Sent: Friday, July 10, 2009 9:27 AM
> > > > > To: [hidden email]
> > > > > Subject: Re: [Ipf-user] Camel 2.x
> > > > >
> > > > > I still plan to help with this.
> > > > >
> > > > > As you all know by now camel-2.0-m2 is out.  However I did not
> > > start on
> > > > > the ipf migration to 2.0 yet.  One of the main reasons are that
> > > actually
> > > > > camel-2.0.0 is planned to be released really soon now, we hope
> this
> > > > > month.  The other, more important one is that there are few api
> > > changes
> > > > > from 20-m2 to 2.0, most notably the disappearance of all the
> > > > > DefaultExchange specialization and changes in the Exchange api
> I will
> > > > > implement in the next few days (see the heated discussions on
> dev@, on
> > > > > which we hope you to participate btw :)).
> > > > >
> > > > > So I have a few questions now.
> > > > > 1.  Do you want a intermediate migration to 2.0-m2, although
> another
> > > > > migration to 2.0 will be necessary?
> > > > > 2.  Do you want to support java5 (camel does) or you don't
> really care
> > > > > about that.
> > > > >
> > > > > Thanks
> > > > > Hadrian
> > > > >
> > > > >
> > > > > On May 28, 2009, at 2:07 AM, Martin Krasser wrote:
> > > > >
> > > > >  
> > > > >> Hadrian,
> > > > >>
> > > > >> Great news! We highly welcome your help, thanks a lot! I just
> > > created
> > > > >> a Wiki page, with some initial entries related to IPF 2.0 and a
> > > Camel
> > > > >> 2.0 upgrade. Lets extend it as we go along. This page can
> also be
> > > used
> > > > >>    
> > > > >
> > > > >  
> > > > >> to collect further community feedback about what should go
> into IPF
> > > > >> 2.0 (section 'wishlist').
> > > > >>
> > > > >> http://repo.openehealth.org/confluence/display/ipf/IPF+2.0
> > > > >>
> > > > >> There will be an experimental 2.0 branch available as soon as
> > > > >> IPF-1.7-m1
> > > > >> is out.
> > > > >>
> > > > >> Cheers,
> > > > >> Martin
> > > > >>
> > > > >> Hadrian Zbarcea schrieb:
> > > > >>    
> > > > >>> If you want, I can help with that.
> > > > >>> Hadrian
> > > > >>>
> > > > >>> On May 27, 2009, at 3:51 PM, Martin Krasser wrote:
> > > > >>>
> > > > >>>
> > > > >>>      
> > > > >>>> Italo Giovani Stefani schrieb:
> > > > >>>>
> > > > >>>>        
> > > > >>>>> I know the IPF 1.6 works fine for Camel .16.
> > > > >>>>>
> > > > >>>>> I need to use Camel 2.0. Is there a dead line to launch a
> > > Camel 2.0
> > > > >>>>>          
> > > > >
> > > > >  
> > > > >>>>> compatible version?
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>          
> > > > >>>> Right now we didn't start to upgrade IPF to use Camel 2.0. The
> > > main
> > > > >>>> reason is that Camel 2 is not backwards compatible to Camel 1.
> > > There
> > > > >>>>        
> > > > >
> > > > >  
> > > > >>>> are many API changes. At the moment I cannot estimate the
> > > effort and
> > > > >>>>        
> > > > >
> > > > >  
> > > > >>>> the issues for such an upgrade. I plan to create an
> > > experimental IPF
> > > > >>>>        
> > > > >
> > > > >  
> > > > >>>> branch (using Camel 2.0) in Q3/2009 and hope to have a first
> > > > >>>> milestone release ready early Q4/2009.
> > > > >>>>
> > > > >>>> Hope that helps,
> > > > >>>> Martin
> > > > >>>>
> > > > >>>>        
> > > > >>>>> Regards
> > > > >>>>>
> > > > >>>>> Italo Giovani Stefani
> > > > >>>>> Vetta Technologies -
> www.vettatech.com<http://www.vettatech.com/>
> > > > >>>>> TEL +55 31 4062-7227 ext 5045 FAX +55 31 4062-7227 ext 6002
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > -------------------------------------------------------------------
> > > > >>>>> -----
> > > > >>>>>
> > > > >>>>> _______________________________________________
> > > > >>>>> Ipf-user mailing list
> > > > >>>>> [hidden email]
> > > > >>>>> http://gforge.openehealth.org/mailman/listinfo/ipf-user
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>          
> > > > >>>> _______________________________________________
> > > > >>>> Ipf-user mailing list
> > > > >>>> [hidden email]
> > > > >>>> http://gforge.openehealth.org/mailman/listinfo/ipf-user
> > > > >>>>
> > > > >>>>        
> > > > >>> _______________________________________________
> > > > >>> Ipf-user mailing list
> > > > >>> [hidden email]
> > > > >>> http://gforge.openehealth.org/mailman/listinfo/ipf-user
> > > > >>>
> > > > >>>
> > > > >>>      
> > > > >> _______________________________________________
> > > > >> Ipf-user mailing list
> > > > >> [hidden email]
> > > > >> http://gforge.openehealth.org/mailman/listinfo/ipf-user
> > > > >>    
> > > > >
> > > > > _______________________________________________
> > > > > Ipf-user mailing list
> > > > > [hidden email]
> > > > > http://gforge.openehealth.org/mailman/listinfo/ipf-user
> > > > >
> > > > > _______________________________________________
> > > > > Ipf-user mailing list
> > > > > [hidden email]
> > > > > http://gforge.openehealth.org/mailman/listinfo/ipf-user
> > > > >
> > > > >  
> > > >
> > > > _______________________________________________
> > > > Ipf-user mailing list
> > > > [hidden email]
> > > > http://gforge.openehealth.org/mailman/listinfo/ipf-user
> > > InterComponentWare AG:
> > > Vorstand: Peter Reuschel (Vors.), Norbert Olsacher /
> > > Aufsichtsratsvors.: Prof. Dr. Christof Hettich
> > > Firmensitz: 69190 Walldorf, Industriestraße 41 / AG Mannheim HRB
> > > 351761 / USt.-IdNr.: DE 198388516
> > >
> ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Ipf-developer mailing list
> > > [hidden email]
> > > http://gforge.openehealth.org/mailman/listinfo/ipf-developer
> > >  
> >
> > _______________________________________________
> > Ipf-developer mailing list
> > [hidden email]
> > http://gforge.openehealth.org/mailman/listinfo/ipf-developer
> InterComponentWare AG:
> Vorstand: Peter Reuschel (Vors.), Norbert Olsacher /
> Aufsichtsratsvors.: Prof. Dr. Christof Hettich
> Firmensitz: 69190 Walldorf, Industriestraße 41 / AG Mannheim HRB
> 351761 / USt.-IdNr.: DE 198388516
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ipf-developer mailing list
> [hidden email]
> http://gforge.openehealth.org/mailman/listinfo/ipf-developer
>  

_______________________________________________
Ipf-developer mailing list
[hidden email]
http://gforge.openehealth.org/mailman/listinfo/ipf-developer