[
Lists Home |
Date Index |
Thread Index
]
On Tue, 2002-08-20 at 20:23, Dare Obasanjo wrote:
> The fact that namespace declarations and in-scope namespaces are treated
> differently in various W3C specs is something I am familiar with and
> have written about[0]. However this is not something that is equates to
> DIFFICULTY in dealing with namespaces given that Joe Blow developer
> doesn't spend his time reading W3C specs. I read on average 10 - 20
> posts a day on our XML related newsgroups and when I hear about
> DIFFICULTY with namespaces it typically takes two flavors of questions
If I interpret this correctly, it is a challenge to give real-life
examples of difficulties, on the part of developers, in dealing with
namespaces.
All right. Some background: I work for a corp (no, not Talsever) that
does a great deal of B2B and EAI stuff. The corp is moving toward XML
as data representation (customer demand, largely), and so purchased the
company I hired into, a little XML startup. Lots of serious XML
expertise here; lots of serious enterprise expertise (and close
attention to performance issues) in the parent. I get called upon to
straighten things out when someone, probably very sharp, possibly
antipathetic towards XML (the usual performance anxieties) gets into a
bind with our APIs and toolchain, or public APIs that we recommend.
1. Carefully constructed code, complete with a comment that the "bug has
been reported to the Xerces team with no response", to "fix" the
assignment of names of unqualified attributes by Xerces. The author was
so convinced that unqualified attribute names needed to be coerced into
the default namespace that he wrote some quite nice code that does so.
Software that uses this code tends to behave peculiarly, to say the
least (it's fine as long as there is no default namespace; then the
attributes stay unqualified (the comment says this part is still "to
do", fortunately)). Encountered once, but interesting evidence of
powerful convictions of how namespaces "ought to work" by a very
competent (but not highly XML skilled) developer.
2. API users who have written schemas using the usual defaults
(elementFormDefault qualified, attributeFormDefault unqualified) get
into a fidget when their instances don't validate (because they assign
namespace-qualified names to attributes, instead of unqualified ones).
In one of the three occasions that I recall, the developer became
increasingly hostile to discussion of the behavior of attributes,
leading to:
3. API users who have generated schemas with attributeFormDefault
qualified. Testing with namespaced attributes works great, but when
they try to "simplify the serialization" by using the default namespace,
everything breaks. This time it's because the namespace isn't declared,
and trying to explain that elements can be unqualified and in a
namespace, but attributes can't, is a somewhat painful exercise. Tow
occasions, one of them a direct result of revision of schema due to item
#2; after that a different developer was given responsibility for the
XML problem and the first became a general opponent XML for any use.
4. Namespace mangling due to the ability to define an attribute in DOM
which, on serialization, turns into a namespace declaration. I forget
how many times I've dealt with this one, at least five; sometimes it's
done on purpose by one developer (as a hack to attach a namespace
declaration, by adding the attribute and forcing a reparse) and broken
by a maintainer (who wants to improve performance by removing the
"redundant" parse).
5. Lots of irritation that the namespace URI isn't the location of the
schema, and that schemaLocation and friends aren't reliable. Is that a
namespace issue?
6. Several instances of the use of java.net.URL for normalization of a
namespace URI that breaks comparability. This leads to explanations
that "a namespace URI is *not* a [java.net.]URL!"
7. One rather embarrassing attempt to assign the default namespace to
the URI of the namespaces rec. This was because the person didn't think
that they could use the xmlns prefix without declaring it, so they tried
to declare it, which instead put all of the elements into the XML
Namespaces namespace, which got really surreal. Major ha-ha, and the
developer was perfectly willing to be corrected, but a rather suggestive
sort of error (this was a developer a little more willing to incorporate
XML, who got just enough knowledge to be dangerous).
*sigh* I envy the folks who get to give presentations, instead of doing
crisis management/problem resolution. Items two through four I've
encountered often enough to think of them as problems, but documenting
stuff only helps when folks read the docco. Five is cataloging, six is
related to the fact that namespaces are case-sensitive strings rather
than URLs, and seven is more of a giggle than a problem.
Does that help any?
Amy!
--
Amelia A. Lewis amyzing@talsever.com alicorn@mindspring.com
You like the taste of danger, it shines like sugar on your lips,
and you like to stand in the line of fire
just to show you can shoot straight from your hip.
There must be a 1000 things you would die for;
I can hardly think of two.
-- Emily Saliers
|
