harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Miguel Montes" <miguel.mon...@gmail.com>
Subject Re: [classlib][html] Should we try to be binary compatible with Sun's bdtd?
Date Wed, 26 Jul 2006 17:28:36 GMT
On 7/26/06, Stefano Mazzocchi <stefano@apache.org> wrote:
>
> Miguel Montes wrote:
> > On 7/26/06, Stefano Mazzocchi <stefano@apache.org> wrote:
> >>
> >> Miguel Montes wrote:
> >>
> >> > The method is public, so anyone can use it to read his own DTD.
> >>
> >> Wait, what method are we talking about?
> >
> >
> > 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).
> > 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)
> > or
> > 2) Figure it out, and document it
> > or
> > 3) Release our own specification
>
> 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).
>
> 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)
>
Tim suggested  NOT trying to figure it out. I would like a bit of
clarification on what are we allowed or not to do.
There are a lot of situations where the specification is ambiguous or
inexistent, and we have to examine the behavior of the RI. I believe there
was some discussion in this list about the protocol used in RMI, which isn't
specified either.
I think that examining the format of something that is a parameter of a
public method should be allowed, but I won´t do that until I'm sure I'm not
messing up.


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message