Thread: RE: RE : [Springframework-developer] DTD

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi everyone,

I'm also for breaking backward compatibility now. I guess the hassle =
will only get more if we don't.

Regarding DTD retrieval: Hibernate uses a respective implementation of =
org.xml.sax.EntityResolver to avoid loading public URIs via HTTP, =
looking up "http://hibernate.sourceforge.net/" URIs in the classpath =
under "net/sf/hibernate/" (contained in the Hibernate JAR). Maybe we can =
adopt a similar approach.

Unfortunately, there's an issue when executing Hibernate within JUnit =
(console version): It doesn't find its classpath DTDs then, falling back =
to the HTTP download. This has probably something to do with JUnit's =
classloading behavior, but I haven't been able to figure it out yet.
I currently have an issue with Hibernate when executing within JUnit.

Juergen

-----Original Message-----
From: JP Pawlak [mailto:jp....@ti...]
Sent: Friday, May 30, 2003 4:00 AM
To: tri...@tr...; 'Rod Johnson'
Cc: spr...@li...
Subject: RE : [Springframework-developer] DTD

Hi Rod,

I agree with Thomas for breaking backward compatibility now. As long as
it is not released, only a few people have to change their files.

For validating: it has to be checked how the parser retrieve the DTD
based on its name (before the URI). It's normally parser dependent. The
URI gives a chance to found it anyway. This name has to be fixed using
the convention "-//<organisation>//<format inside the
organisation>//<language>".

Jean-Pierre

> -----Message d'origine-----
> De : spr...@li...=20
> [mailto:spr...@li...]
>  De la part de tri...@tr...
> Envoy=E9 : vendredi 30 mai 2003 03:31
> =C0 : Rod Johnson
> Cc : spr...@li...
> Objet : Re: [Springframework-developer] DTD
>=20
>=20
> Rod,
>=20
> I vote for breaking backward compatibility now, before the=20
> first release.  As soon as you release a deprecated feature,=20
> you know that there is always someone that is going to use it=20
> and later complain when it is gone :-)
>=20
> As for the DTD, could it go in the package where the=20
> DocumentBuilderFactory lives?  If the XML files are not=20
> valid, how are you going to use them - guess what is missing?=20
>  I'd say force them to be valid as long as whe throw a=20
> clearly worded exception if they are not.
>=20
> --Thomas
>=20
>=20
> > I knew I forgot some further questions:
> >=20
> > - Where should the DTD go?
> > - Should we require all XML files to be valid?
> >=20
> > - How long should I retain the present backward compatibility in=20
> > parsing XML? 0.8? 0.9? Break it now?
> >=20
> > Regards,
> > Rod
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.net email is sponsored by: eBay
> > Get office equipment for less on eBay!=20
> > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> > _______________________________________________
> > Springframework-developer mailing list=20
> > Spr...@li...
> >=20
> https://lists.sourceforge.net/lists/listinfo/s>
pringframework-developer
> >=20
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!=20
> http://adfarm.mediaplex.com/ad/ck/711-11697-> 6916-5
>=20
> _______________________________________________
>=20
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20

-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer