xml-dev - Re: SAX2: Interning names in namespaces

[terje@in-progress.com (Terje Norderhaug)]

At 9:01 AM 2/6/00, Stefan Haustein wrote:
>Terje Norderhaug wrote:
>> At 4:46 AM 2/5/00, Stefan Haustein wrote:
>> > Terje Norderhaug wrote:
>
>> >> I suggest that parsers interns each name as a separate string in the
>> >> namespace it belong to. This should guarantee that two equal names in the
>> >> same namespace are identical, and that two equal names in different
>> >> namespaces are unidentical.
>> >
>> >Sounds too complicated for broad acceptance [...]
>>
>> It is straight-forward to implement. Here is pseudo code for one possible
>> implementation using hash tables:
>
>Ok, replace "complicated" by "unconvential". I do not like
>the idea off putting "hidden" meanings to string1 == string2.
>Normaly, someone unfamiliar with the concrete implemention
>would expect that both strings are java-interned.

>Also, you
>would not be able to compare just against a constant. You
>would need to ask the parser for the "right" String Object
>corresponding to a concrete namespace/name combination for
>comparison.

Not so. Just compare names on equality if namespaces aren't significant.

>My main argument (you did not qoute) was that
>I am in doubt if your suggestion is really good OOP. A
>cleaner OO approach would probably be having a QName class
>/ interface with the corresponding compare methods.
>But we already had this discussion, and the conclusion
>was to stay at the String based interface.

Exactly. So let's see what we can do with a String based interface as
starting point.

My proposal allows staying with a String based representation of names
while not precluding using a compund object instead. With the invariants,
SAX2 don't have to specify the representation of a name but can leave that
to implementations. Some may choose to use strings for backward
compatability and simplicity, others may choose to use a compund object in
good OO tradition.

I would like to see an interface for Name, but it is not required by my
proposal. The suggested invariants allow supporting a compound interface
for names even if they are represented as localname strings. I have for
example shown that you can determine the namespace of a localname string as
long as it is interned in a namespace, without having to encode any
namespace information in the string. If SAX2 included an interface for
names, it would be up to the implementation whether it used a String or a
Name object to represent names.

>As far as I remember, the reasons were
>
>1. maximum performance / simplicity (SAX is a low level,
>   driver-like interface)

I claim that my proposal allows even more simplicity that in the current
SAX2 beta, as namespace URIs don't have to be passed along with localname
strings to support namespaces.

>2. there was no agreement about the semantics of equals
>   in several cases

The reason was that the same name had multiple instances. This is solved
with the invariants:

>> Given that names are interned in namespaces, one only have to test whether
>> the two names are identical to determine whether the two names are the
>> same:
>>
>>   name1 == name2
>>
>> Note that in the latter case, comparing namespaces are no longer required.
>> This allows major simplifications of code as one no longer have to pass
>> namespaces with names.
>
>I do not agree: the problem is, you cannot any longer compare against
>constants like
>
> if (namespace.equals ("http://www.my.com/mynamespace")) {
>    if (name.equals ("price")) ....
>    else if (name.equals ("quantity")) .....

Sure you can, as you can get the namespace from the localname:

if (name.namespace.equals ("http://www.my.com/mynamespace")) {
  if (name.equals ("price")) ....
  else if (name.equals ("quantity")) .....

>you would need something like: [TN substituted parser.getUnique with
>internName]
>
>  String myPriceElement = internName("http://www.my.com/mynamespace", "price");
>  String myQtytyElement = internName("http://www.my.com/mynamespace",
>"quantity");
>
>  if (name == myPriceElement) ....
>  else if (name == myQtytyElement) ....

I actually think the latter is much better. Using constants for the names
makes the code more readable and is a good programming habit that foster
maintainanble code. It also moves much of the processing to compile time
rather than run-time, which may boost performance. You may also be able to
use programming constructs like case/switch instead of long if/else
statements, leading to cleaner code.

However, my proposal doesn't require that names are interned as constants,
but gives you a choice when comparing names.

-- Terje <terje@in-progress.com> | Media Design in*Progress

   Software for Mac Web Professionals at <http://www.in-progress.com>
   Take advantage of XML with Emile, the first XML editor for Mac!