Re: [classlib][html] Should we try to be binary compatible with Sun's bdtd?

[Diego Mercado <me...@gmail.com>]

HARMONY-948 has a serialized dtd file called transitional401.bdtd.
When I try to read it by calling DTD.read(DataInputStream) I get a
java.io.EOFException. But, on the other hand, when I create a binary
DTD by calling DTDUtilities.create(String) I can get it with succeed.

How can I read transitional401.bdtd file? I used the JRE Harmony
424571 release in GNU/Linux.

Thanks,

Diego Mercado

On 7/28/06, Miguel Montes <mi...@gmail.com> wrote:
> On 7/28/06, Stepan Mishura <st...@gmail.com> wrote:
> >
> > On 7/28/06, Miguel Montes wrote:
> > >
> > > So, it seems there is consensus on the following steps:
> > > 1) We ask Sun again about the bdtd specs
> > > 2) We do NOT reverse engineer the bdtd
> > > 3) We choose a format, and document it.
> > >
> > > It also seems that serialization is not the proper way of doing 3), so
> > we
> > > must select a format that doesn't depend on the implementation of, say,
> > > Hashtable, and we remain compatible with future versions of the class
> > > libraries.
> > > What about using ASN.1? We already have a decoder, so it shouldn't be
> > > difficult
> >
> >
> > Yep, using  ASN.1 for binary format seems logical. If we agree on this I
> > can share my experience of working with ASN.1.
>
>
> In fact, I was thinking in using your decoder, Stepan, so  that's great
> news.
>
>
> Thanks,
> > Stepan.
> >
> > On 7/27/06, Ivanov, Alexey A <al...@intel.com> wrote:
> > > >
> > > >
> > > > >-----Original Message-----
> > > > >From: Stefano Mazzocchi [mailto:stefano@apache.org]
> > > > >Sent: Wednesday, July 26, 2006 9:08 PM
> > > > >To: harmony-dev@incubator.apache.org
> > > > >Subject: Re: [classlib][html] Should we try to be binary compatible
> > > > with
> > > > >Sun's bdtd?
> > > > >
> > > > <SNIP>
> > > > >> The method read(DataInputStream). It's poorly  documented, but it
> > > > reads a
> > > > >> DTD in an unspecified binary format. The default DTD is stored in
> > > > this
> > > > >> format in a file named html32.bdtd (or html401.bdtd, in the case of
> > > > the
> > > > >> recent contribution).
> > > >
> > > > This method seems to be undocumented at all until people asked for it
> > > > [1].
> > > >
> > > > >> As Alexey pointed out, there is no method to write a DTD, so maybe
> > > > nobody
> > > > >> uses the method read() anyway. But I see no point in having a
> > public
> > > > >method
> > > > >> that nobody can use. So I think we can:
> > > > >> 1) Ask Sun to release the specification (if there is one)
> > > >
> > > > We should try this once more (The first attempt was made in [1]).
> > > >
> > > > >> or
> > > > >> 2) Figure it out, and document it
> > > > >> or
> > > > >> 3) Release our own specification
> > > >
> > > > Maybe specification is not the right word here. I believe we _can_
> > > > document which format we use. So that anyone can prepare their own
> > > > archive file with DTD, read it using jx.s.t.html.parser.DTD.read, pass
> > > > it to parser.
> > > >
> > > > >
> > > > >since the method is public and part of javax.swing, we need to
> > > > implement
> > > > >it, but this looks like a mistake or an overlook (and there are no
> > > > swing
> > > > >tests in the TCK anyway so we can do whatever we please).
> > > >
> > > > It is not the only place where a public method is present, but it has
> > no
> > > > use because of lack of documentation.
> > > >
> > > > >
> > > > >I think it's safe to try #1 and #2 in parallel with different people.
> > > > >Geir can do #1 while you can do #2.
> > > > >
> > > > >/me loves to delegate ;-) (aka lazy ass mode)
> > > > >
> > > > >I would suggest against #3: specifications are something that we are
> > > > not
> > > > >tasked to do (even to compensate lack of such), as it might deliver
> > the
> > > > >wrong message.
> > > > >
> > > >
> > > > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4216248
> > > >
> > > > Regards,
> > > >
> > > > --
> > > > Alexey A. Ivanov
> > > > Intel Middleware Product Division
> > > >
> > >
> > >
> >
> >
> > --
> > Thanks,
> > Stepan Mishura
> > Intel Middleware Products 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
>
>

---------------------------------------------------------------------
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