[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX2: Interning names in namespaces
At 5:40 PM 2/6/00, David Megginson wrote: >Stefan Haustein <stefan.haustein@t...> writes: > >> 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. > >Agreed -- while the idea (as far as I understand it) is interesting, The idea isn't more unconventional than what already is implied by the Namespace Recommendation. My suggestion involves that SAX2 is consistent with the name identity principle that can be derived from the recommendation: Two equal names are identical only if they are in the same namespace. Let me illustrate with an example: <body> <foo xmlns="http://www.w3.org/foo"> <title>first</title> <title>second</title> </foo> <bar xmlns="http://www.w3.org/bar"> <title>third</title> </bar> </body> According to the Namespace Recommendation, the first and the second "title" names are identical because they are equal and in the same namespace. However, the third "title" name is not identical to the previous ones because it is in another namespace. That the third name is equal is of no significance, it could just as well have been called "subject". A parser implementing the SAX2 beta would present the three "title" names as equal, but it doesn't specify whether they are identical. Names in SAX2 thus breaks with the name identity principle of the Namespace Recommendation. SAX2 requires taking the extra step of explicitely testing the namespace to determine the identity of names. Some have suggested that SAX2 requires Java-interned names. If so, the three "title" names would be identical. This breaks with the name identity principle of the Namespace Recommendation, which implies that the third name is not identical to the previous ones. If the parser interns each name in its namespace, the name identity principle holds: The first and the second "title" name in the example will be identical, while the third will be a different name even if it is equal characterwise. >I'm not comfortable with any serious obfuscation, no matter how >clever. I've been coding for money long enough (13 years, believe it >or not) to have seen many examples of this kind of thing, and I cannot >remember a single one that did more good than harm in the long run. > >Besides, XML parsing itself is confusing enough for non-specialists >(i.e. 99.99% of SAX's target market). Interning names in namespaces won't make ut harder for non-specialists. If anything, it will make it easier to use SAX. Let me illustrate how the proposal affects different groups of SAX users: BEGINNERS A "beginner" is somebody that know simple programming or scripting, but don't grasp more advanced issues such as namespaces. The extra namespace arguments that SAX2 introduces for several central methods are likely to confuse beginners, making it hard for them to figure out what should be compared and what can be ignored. My proposal allows SAX2 to pass localnames as strings without having to pass namespace URI's. This means that beginners don't have to deal with namespace information, making it easier to use SAX. Beginners can simply ignore namespaces all together and compare names on equality: if (name.equals ("price")) .... else if (name.equals ("quantity")) ..... SCRIPTERS A "scripter" is somebody that know string manipulation and other basic programming used commonplace in scripts, and have some graps of the namespace recommendation, but don't understand pointers and the difference between equality vs identity on a practical level. Scripters handle string-based arguments well and may find it convenient to have the namespace URI separted from the localname in the argument list of startElement and similar methods, so they can make comparasions like: if (namespace.equals ("http://www.my.com/mynamespace")) { if (name.equals ("price")) .... else if (name.equals ("quantity")) ..... However, scripters shouldn't have much problems to get the namespace from the name instead of having it as a separate argument. This code that performs the same as the example above but without requiring the namespace to be passed as a separate item in methods like startElement: if (name.namespace.equals ("http://www.my.com/mynamespace")) { if (name.equals ("price")) .... else if (name.equals ("quantity")) ..... As I have shown, the difference in the code is minor. In fact, scripters may very well find it easier to use names when they can get the namespace URI from the localname rather than be required to pass a namespace URI with each localname. PROGRAMMERS A "programmer" understands the implications of the namespace recommendation and are savvy in object oriented programming. Programmers are free to use SAX like beginners and scripters as they see fit. However, given that names are interned in namespaces, they are free to use identity to compare names: String myPrice = internName("http://www.my.com/mynamespace", "price"); String myQtyty = internName("http://www.my.com/mynamespace", "quantity"); if (name == myPrice) .... else if (name == myQtyty) .... Under the proposal, programs that use SAX won't have to deal with namespace representations at runtime. Unless names are interned in namespaces, specialists would be limited to the less efficient techniques of beginners and scripters when using SAX. In conclusion, interning names in namespaces makes it easier to use SAX while still allowing more efficient techniques for savvy programmers. The proposal makes SAX2 consistent with the name identity principle derived from the Namespace Recommendation. -- 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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|