Miguel, Does it make sense using ASN.1 then, if it's complex and not pretty? OTOH formal description is an advantage.
I believe we can write the data needed with just DataOutputStream methods, but it might not be clear. We can improve serialization so that it works fine and in JVM-independent way by overriding readObject/writeObject methods in the classes to be serialized. (The classes under consideration are from html.parser package, I believe so.) Regards, -- Alexey A. Ivanov Intel Middleware Product Division >-----Original Message----- >From: Miguel Montes [mailto:[EMAIL PROTECTED] >Sent: Wednesday, August 02, 2006 8:40 PM >To: harmony-dev@incubator.apache.org >Subject: Re: [classlib][html] Should we try to be binary compatible with >Sun's bdtd? > >As I suggested earlier, I would use ASN.1. I don't like it, but there are >several arguments for using it: >1) We can make a formal description of the format, so anyone can write his >own encoder/decoder. Something like: > >BDTD ::= SEQUENCE { > Entity SET OF HTMLEntity, > Element SET OF HTMLElement >} > >HTMLEntity ::= SEQUENCE { > Name NameId, > Type HTMLEntityType, > Data OCTET STRING >} > >NameId ::= OCTET STRING >2) We already have an ASN.1 encoder/decoder, developed by the people of >Intel Middleware Product Division (Stepan and others). It is used in the >crypto framework, so it must be included in Harmony, anyway. > >It's complex, and it's not pretty. I wouldn't suggest it if we didn't >already have the decoder available. But it is there, and we can use it. > > >On 8/2/06, Ivanov, Alexey A <[EMAIL PROTECTED]> wrote: >> >> Diego, >> >> I tried to read this file using both J9 and DRLVM, and I didn't manage. >> Hence using serialization is not the best approach, and we need to >> choose another archive format. >> >> Serialization might fail because it contains some classes which >> serialized form is not specified (Element, Entity etc.) and which don't >> contain serialVersionUID field. >> >> We may use DataOutputStream methods to save the required information, >> and directly use DataInputStream to read it. (However using >> serialization looks simpler.) >> >> >> Any ideas about the binary format? >> >> Regards, >> -- >> Alexey A. Ivanov >> Intel Middleware Product Division >> >> >> >-----Original Message----- >> >From: Diego Mercado [mailto:[EMAIL PROTECTED] >> >Sent: Wednesday, August 02, 2006 1:36 AM >> >To: harmony-dev@incubator.apache.org >> >Subject: Re: [classlib][html] Should we try to be binary compatible >> with >> >Sun's bdtd? >> > >> >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 <[EMAIL PROTECTED]> wrote: >> >> On 7/28/06, Stepan Mishura <[EMAIL PROTECTED]> 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 <[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] >> >> > >> >> > >> >> >> >> >> >> -- >> >> Miguel Montes >> >> >> >> >> > >> >--------------------------------------------------------------------- >> >Terms of use : http://incubator.apache.org/harmony/mailing.html >> >To unsubscribe, e-mail: [EMAIL PROTECTED] >> >For additional commands, e-mail: [EMAIL PROTECTED] >> >> --------------------------------------------------------------------- >> 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 --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
