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 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 --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Miguel Montes
