harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Petrenko" <alexey.a.petre...@gmail.com>
Subject Re: [classlib][html] Should we try to be binary compatible with Sun's bdtd?
Date Wed, 26 Jul 2006 14:24:35 GMT
2006/7/26, Miguel Montes <miguel.montes@gmail.com>:
> On 7/26/06, Ivanov, Alexey A <alexey.a.ivanov@intel.com> wrote:
> >
> >
> > >-----Original Message-----
> > >From: Tim Ellison [mailto:t.p.ellison@gmail.com]
> > >Sent: Wednesday, July 26, 2006 1:32 PM
> > >To: harmony-dev@incubator.apache.org
> > >Subject: Re: [classlib][html] Should we try to be binary compatible with
> > >Sun's bdtd?
> > >
> > >On 25/07/06, Miguel Montes <miguel.montes@gmail.com> wrote:
> > >> Hi:
> > >> Working on the HTML parser, I found the following problem.
> > >> The HTML parser can be parameterized by a DTD. The class
> > >> javax.swing.text.html.parser.DTD has a method read(DataInputStream),
> > that
> > >> reads a DTD in binary format. AFAIK, there is no public specification
> > of
> > >> this format, and the recent contribution of the HTML component
> > (HARMONY-
> > >948)
> > >> seems to use its own binary format.
> > >> Although I donĀ“t know if there are applications out there using this
> > >method
> > >> to load custom DTDs, the method is public, so I think we should be
> > >> compatible with Sun. That is, we should be able to read Sun's bdtd, and
> > >our
> > >> bdtd should be readable by Sun's implementation.
> > >
> > >I agree that it would be good to aim for interoperability here.
> > >
> > >> Am i missing something? Does anyone know if there is a specification?
> > Is
> > >it
> > >> OK to reverse engineer the file "html32.bdtd"?
> > >
> > >I don't know of a spec, if you don't find one after some searching it
> > >may be something we want to go back and ask Sun.  I recommend that you
> > >don't reverse engineer their implementation/format to figure it out.
> > >In the meantime we shall have to remain incompatible.
> >
> > I don't know about any spec. The bug on Sun site [1] seems to prove there
> > is no spec for the binary format of DTD.
> >
> > In this implementation binary format is just a serialized version of DTD
> > based on HTML 4.01 Transitional.
> >
> > Why do we need to read the binary DTD of Sun? Harmony classlib will have
> > its own bdtd, which it is able to deal with. IMHO if we need to, we can
> > create our own html32.bdtd.
>
>
> The method is public, so anyone can use it to read his own DTD. If it were
> private, or with package visibility, there wouldn't be any problem. The
> problem is with Sun's design. The implementation is completely exposed, with
> a lot of public fields. But being the method public, I think we should be
> interoperable. If someone decides to build his own DTD, it should work with
> any implementation.
+1!


> Maybe what i'm saying is not even possible. Maybe there is no such thing as
> a "Sun format", and they don't even try to preserve compatibility between
> versions. (although I tested that the JDK 1.5 can read the bdtd from 1.4.2).
>
>
> But that leads to another question. Doesn't the use of serialization tie us
> to a specific version of the class? What if the implementation changes? If
> we are not going to support Sun's format, I think we shouldn't make the same
> mistake as them. We should define a format, make it public, and adhere to
> it.
>
>
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4216248
> >
> > Regards,
> > Alexey.
> >
> > >
> > >Regards,
> > >Tim
> > >
> > >--
> > >
> > >Tim Ellison (t.p.ellison@gmail.com)
> > >IBM Java technology centre, UK.
> >
> > --
> > Alexey A. Ivanov
> > Intel Middleware Product Division
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
>
> --
> Miguel Montes
>
>


-- 
Alexey A. Petrenko
Intel Middleware Products Division
Mime
View raw message