[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SAX2: Interning names in namespaces

  • From: terje@i... (Terje Norderhaug)
  • To: xml-dev <xml-dev@x...>
  • Date: Sun, 6 Feb 2000 13:07:16 -0800

compare names
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@i...> | 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!



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.