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. Thanks, Stepan. On 7/27/06, Ivanov, Alexey A <[EMAIL PROTECTED]> wrote:
> > > >-----Original Message----- > >From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] > >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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
