[
Lists Home |
Date Index |
Thread Index
]
- From: terje@in-progress.com (Terje Norderhaug)
- To: xml-dev <xml-dev@xml.org>
- Date: Mon, 7 Feb 2000 12:06:22 -0800
At 5:40 PM 2/6/00, David Megginson wrote:
>Stefan Haustein <stefan.haustein@trantor.de> 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@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!
|
