[EMAIL PROTECTED] wrote:
> Is there any reason for using XMLString in some places while not
> using it in others ?
Ummm... seemed like a good thing at the time...? Actually,
some of the design decisions seem kinda arbitrary now. We
haven't closed the books on the design, yet, so everything
is still open to discussion.
> In particular, I noticed XMLString is used for char data, PI
> data, and few other places, but it is not used for attribute
> values.
Good point. We can certainly make attribute values XMLStrings.
But String seemed to make more sense because we normally have
to do normalization of the attribute value anyway. Also, the
standard interfaces pass attribute values as strings so it
seemed fine that they were made into strings up front.
> Another question is related with XMLString.toString(). It
> seems it allways calls new String(), I think it would help to
> cache the conversion result, in case someone will call this
> method later.
This is a pretty good idea. The only problem is that the
fields of XMLString are public which makes keeping the data
values and the cached string value in sync hard to manage.
I tried to avoid making XMLString an actual object with
accessor methods for the pieces of data. This would have
introduced performance overhead that wasn't really needed.
> IMHO it would be much better if XMLString would be used consistently in
> all places where a String is used, and maybe enhanced with few utility
> methods that could avoid creating the String in common processing
> ( like compare with a String, etc ). This will allow XNI to operate
I'm all for consistency. And having some utility methods
would be nice -- just don't want to go overboard and blow
up the structure too much. As a starting point for the
discussion, why don't you post how you would design the
XMLString class. And then we can go from there.
--
Andy Clark * IBM, TRL - Japan * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
