Crimson says namespace attribute must preceed other attributes -- true?

[Scott Sauyet]

Hi folks, I'm new to this neighborhood. If my question should be posed
elsewhere, I would appreciate a pointer as to where. Thanks.


It took me a while to chase down what the Crimson parser was talking
about with this exception: "java.lang.IllegalStateException: can't
declare any more prefixes in this context", but I got it. It means
that it wants to see no attributes defined before the namespace
attribution declaration. For instance,

<myns:element name="xyz" xmlns:myns="this fails" ... >

<myns:element xmlns:myns="this works" name="xyz" ... >

A developer working for a client tells me that this restriction is
"straight out of the XML spec", but I can't find a reference anywhere.
I was wondering if I'm missing something, or if this is true. I
thought the namespace declaration was treated like any other attribute.
Any pointer to a reference confirming or refuting that point would be
appreciated.

Unfortunately, the Crimson version is embedded inside WebSphere and I
haven't found a way to isolate a simple test, but when I reorder my
attributes to put the namespace one first, it gets me past the sticking
point. However I run into it again with XML I don't directly control
(written by Apache Axis.) And that seems to have me up against a wall.
I'm imagine that if I learn more about WebSphere configuration, I can
change parsers or configure this one differently, but this is for an
application that is supposed to just drop into an Application/Web
server without need for configuration.

So I guess there are two questions. First, I would like to know if
this behavior is according to spec. Second, I wonder if anyone has run
into this and found a way to get past it.

Thanks for any insight you can offer,

-- Scott Sauyet

 

[Martin Honnen]

Scott Sauyet wrote:

It took me a while to chase down what the Crimson parser was talking
about with this exception: "java.lang.IllegalStateException: can't
declare any more prefixes in this context", but I got it. It means
that it wants to see no attributes defined before the namespace
attribution declaration. For instance,

<myns:element name="xyz" xmlns:myns="this fails" ... >

<myns:element xmlns:myns="this works" name="xyz" ... >

A developer working for a client tells me that this restriction is
"straight out of the XML spec", but I can't find a reference anywhere.
I was wondering if I'm missing something, or if this is true. I
thought the namespace declaration was treated like any other attribute.
Any pointer to a reference confirming or refuting that point would be
appreciated.

Frankly I don't think it is true. First of all the XML specification
does not deal with namespaces at all, there is a separate specification
doing that, and the section here
<http://www.w3.org/TR/REC-xml-names/#nsc-NSDeclared>
in my view obviously allows both constructs you have above. All it says
is that a prefix has to be declared in the start tag of the element
itself or an ancestor but there is no requirement that namespace prefix
declararing attributes need to come first.

Furthermore I have tried the following simple XML

<?xml version="1.0" encoding="UTF-8"?>
<root xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" />

with Crimson in Java JDK 1.4.2_06 as follows without problems:

DocumentBuilderFactory docBuilderFactory =
DocumentBuilderFactory.newInstance();
docBuilderFactory.setNamespaceAware(true);
System.out.println("DocumentBuilderFactory: " + docBuilderFactory);
DocumentBuilder docBuilder = docBuilderFactory.newDocumentBuilder();
System.out.println("DocumentBuilder: " + docBuilder);
Document xmlDocument = docBuilder.parse(args[0]);
Element rootElement = xmlDocument.getDocumentElement();
for (int i = 0, length = rootElement.getAttributes().getLength();
i < length; i++) {
Attr attributeNode = (Attr) rootElement.getAttributes().item(i);
System.out.println("Attribute " + i + ": name: " +
attributeNode.getNodeName() + "; value: " + attributeNode.getNodeValue());
}

The output is

DocumentBuilderFactory:
org.apache.crimson.jaxp.DocumentBuilderFactoryImpl@11a698a
DocumentBuilder: org.apache.crimson.jaxp.DocumentBuilderImpl@17943a4
Attribute 0: name: xlink:type; value: simple
Attribute 1: name: xmlns:xlink; value: http://www.w3.org/1999/xlink

so Crimson parses the XML document without problems.

 

[Scott Sauyet]

Thank you.

I don't think it's true either. I was reading the same part of the
spec, and didn't find anything to that effect, but I'm no expert on the
spec, and wondered if I missed anything.

I haven't isolated the version of Crimson used inside WebSphere or what
sort of configuration is supplied to it, but changing the attribute
order was enough to get through the issue. Because I couldn't believe
that was the problem, I retested several times, just switching the
order back and forth, and that was clearly the issue... very odd.

Thanks for the reply and for going out of your way to run a test.

-- Scott

 

[Richard Tobin]

It means
that it wants to see no attributes defined before the namespace
attribution declaration.

If so, it is completely wrong. The order of attributes in XML is not
significant, and the fact that some attributes are used as namespace
declarations does not change this.

A developer working for a client tells me that this restriction is
"straight out of the XML spec"

It's possible that this mistaken idea comes from the fact that the
XPath data model puts namespace nodes before attributes, but that's
not relevant to the syntax.

-- Richard

 

[Scott Sauyet]

The order of attributes in XML is not

significant, and the fact that some attributes are used as namespace
declarations does not change this.

Thanks for the confirmation. He's the client, and I won't argue with
him about this, but I think I can rest easy that even if I have to fix
it, the problem is not of my own making.

Now, as to configuring WebSphere...

Thanks again,

-- Scott

..SIG trails off mumbling something about overly complex products and
evil empires.

 

[C. M. Sperberg-McQueen]

... it wants to see no attributes defined before the namespace
attribution declaration. For instance,

<myns:element name="xyz" xmlns:myns="this fails" ... >

<myns:element xmlns:myns="this works" name="xyz" ... >

A developer working for a client tells me that this restriction is
"straight out of the XML spec", but I can't find a reference anywhere.
I was wondering if I'm missing something, or if this is true.

I have not re-checked the XML spec or the Namespaces spec,
but I'm pretty sure this restriction is not to be found
there. One reason: I have no recollection of ever having
heard of such a constraint before. No one's memory is
perfect, but I'm pretty sure I'd remember something like
that. An even better indication: I'm still alive. Since
the rest of the WG would have had to kill me, and several
other people, to get anything like that written into either
spec, I take my survival as one piece of evidence that the
specs don't say this.

-C. M. Sperberg-McQueen
World Wide Web Consortium

 

[Malcolm Dew-Jones]

Scott Sauyet ([email protected]) wrote:
: Thank you.

: I don't think it's true either. I was reading the same part of the
: spec, and didn't find anything to that effect, but I'm no expert on the
: spec, and wondered if I missed anything.


http://www.w3.org/TR/2004/REC-xml-20040204/

3.1 Start-Tags, End-Tags, and Empty-Element Tags

(a few lines down)

"Note that the order of attribute specifications in a start-tag or
empty-element tag is not significant.
"

 

[Scott Sauyet]

An even better indication: I'm still alive. Since

the rest of the WG would have had to kill me, and several
other people, to get anything like that written into either
spec, I take my survival as one piece of evidence that the
specs don't say this.

Well, I'm glad to hear you're still kicking.

And yesterday we finally found the root cause of our problems: a
problem in a Java JAR file had our application server mixing and
matching parts of Crimson and Xerces, something I didn't even know was
possible. It was a very strange error. Our development application
server (Tomcat) refused to load anything from the JAR file and worked
perfectly well. Our deployment application server (WebSphere) seemed
to load what it could from that JAR file and got other parts from other
JARs in the classpath or from the Java runtime engine. Some
combination of these multiple Crimson and Xerces parsers was trying to
parse the XML files, and would actually manage to do so successfully,
but only if any attributes without namespace prefixes follows all those
that included prefixes. Very bizzare.

Thanks to everyone who responded. It did help me to feel less crazy.

-- Scott

 

[Scott Sauyet]

Thank you.

What I thought remotely possible was that somewhere in the namespace
spec was something that started something like "Notwithstanding the
irrelevance of attribute order in the general XML specifications, ..."
I didn't expect to find such, but I really wanted to know if this
client's understanding was based on knowledge deeper than mine. I
guess not.

Thanks for the pointer.

-- Scott

 

[Scott Sauyet]

I got an email asking for more information, and I thought I'd post
more of my analysis in case anyone else finds this thread while
searching for this strange error.

Like you, I saw the problems on IBM Websphere's JVM that did not
appear on Tomcat. Your conclusion -- that somehow Xerces and Crimson
classes are getting mixed up -- blew me away. Could you share with
me -- by email or on the same forum -- how you came to that
conclusion? Thanks!

Certainly.

I'm less than convinced of the analysis. It's just as likely an issue
between two different Crimson versions. But something was happening
with the parsers, and our fix was quite simple: We'd been
inadvertently including a version of j2ee.jar (j2ee-1.3.1.jar) --
needed only in our compilation -- inside our webapp; removing it
solved the issue. I hadn't noticed before that Tomcat reported an
error reading a class from that jar file. My guess is that Tomcat
stopped trying to load anything from this .JAR, but that WebSphere
continued to load what it could from there, and ran into a conflict
with the JRE's Crimson version.

The reason I suspect problems with the two parsers has to do with two
facts: The class that failed to load from the JAR was a Xerces class
(I don't recall which one.) And when I added Crimson to our webapp,
Tomcat failed the same way that WebSphere did. Eventually I did a
number of tests with all sorts of combinations of parsers in three
places: our webapp, Tomcat itself, and the JRE.

For the JRE, I hacked a version of Sun's rt.jar by removing the
crimson classes, and sometimes added Xerces JARs to the endorsed
folder. Or I used the standard rt.jar. For Tomcat, I used the
default with Xerces in the endorsed folder, or with Crimson replacing
it, or with nothing in there. In my own app, I either included
crimson.jar or I didn't. This meant 18 different tests:

In this chart, "-" means there is no parser, "C" means crimson was
present, "X" means that Xerces was present. (This probably will only
look right in a fixed-width font.)

JRE Tomcat Webapp Results
=== ====== ====== =======
- - - Tomcat won't start -- no surprise
- - C Tomcat won't start -- no surprise
- C - success
- C C success
- X - success
- X C parsing fails
C - - success
C - C success
C C - success
C C C success
C X - success
C X C parsing fails
X - - success
X - C success
X C - success
X C C success
X X - success
X X C parsing fails

I did a few other random tests, too, though not as systematically,
including these two:

JRE Tomcat Webapp Results
=== ====== ====== =======
- C & X - success
- C X success

It seems that the common issue with all the failures had to do with
having Xerces in Tomcat and Crimson in our webapp. It was that which
made us take another look at the JAR files in our webapp. We had been
careless, simply using the same Ant Fileset for compilation and for
inclusion in the webapp. It didn't make sense to include the j2ee.jar
in the webapp, and we would have caught it early in Tomcat or JBoss
development if not for the classloading issue. But until now all our
clients had deployed to Tomcat or JBoss and we hadn't gone through the
hassle of downloading and configuring WebSphere.

So, if you're still having such an issue, I would suggest that you
take a look at any JARS you're deploying in your webapp and see if
there is a copy of Crimson in one of them. If there is, see if it
works without that JAR. It also helped us clean up our distribution,
cutting the size of our WAR file by more than half!

Good luck,

-- Scott