For the public/system Id, I have to agree with you 100%. Can you add your reflection code to both BaseMarkupSerializer and OutputFormat.
For the constructor there are two possibilities: 1. Document the behavior. That is already the case. 2. Eliminate the constructor, preventing the possiblity of getting the serializer in an inconsistent state. As far as I can recall there was no such constructor in the original code base, but at least two people asked for it, so I added it. I never use it myself. It's a +1 on my side to drop it. arkin Andy Clark wrote: > > Assaf Arkin wrote: > > They have no right to complain, but they will and I don't want to answer > > them. Throwing IllegalStateException solves that in an elegant way. > > I would disagree with this solution as being elegant. My > personal opinion is that objects should not start off in an > unusable state. Requiring the programmer to have explicit > knowledge of what needs to be done in order to get the > object into a usable state is asking for trouble. Also, the > default action of throwing an exception is a problem because > you can't know that your program is in a usable state until > runtime. While we can't perform compile time checks, we can > make the object safe by default construction. > > > I was rather hoping that people will use the OutputFormat to do that for > > the time being. OutputFormat will also take the system/public ids from > > the document type in DOM Level 2. > > Yes, but if you assume that the DOM tree that you are > handed is DOM Level 2 and attempt to call the method (when > it's really a DOM Level 1 implementation), you will get a > runtime exception thrown by the VM. At least the reflection > makes it work before (and after) the W3C interfaces become > standard and while they're being adopted. > > > I don't think reflection is a good way. Besides I can always cast it to > > the proper Xerces type as a temporary solution. > > Should we assume that the DOM tree handed to the serializers > is always going to be from Xerces? I would vote for allowing > everyone to use our serializers, regardless of whether they > use our DOM implementation. > > > Because it has no way of knowing what is external and what is internal. > > The DOM serializer simply dumps everything. The only solution is for the > > DOM serializer to not print anything, which is what I think I'll do > > after I get it to print correctly. > > I agree with not printing anything. > > -- > Andy Clark * IBM, JTC - Silicon Valley * [EMAIL PROTECTED] -- ---------------------------------------------------------------------- Assaf Arkin www.exoffice.com CTO, Exoffice Technologies, Inc. www.exolab.org
