Namespace prefix starting mit xml are marked as illegal

[michael-o]

I am using JDOM with JMeter and the XML Assertion. My sample unfortunately includes following element:

 <XMLFault:XMLFault>...</XMLFault:XMLFault>

So, unfortunately, the producing service uses a custom namespace prefix beginning with "xml". According to this one SHOULD NOT use such a prefix and the processor MUST NOT fail.

JDOM fails. This is erractic behavior.

[rolfl]

Ouch. OK, I understand your predicament. This is not something trivial to fix because JDOM cannot simply blanket-accept xml-prefixed namespace values. There will need to be some sort of configuration to 'disable' the error-handling.... in a few places.

Do you have a suggestion as to how you would like to see it fixed? (not the code changes, but a desription of the behaviour - although code-changes would be acceptable too ;-) It will still need to disallow users from creating xml-starting namespaces.

[rolfl]

Is it possible for you to provide a full example XML document I can test against? I guess I coud manufacture one myself, but would prefer your use-case.

[hunterhacker]

Why can't we blanket-accept xml-prefixed namespace prefixes? Isn't that what the spec is telling us we must do?

So just remove the Verifier check:

    // Cannot start with "xml" in any character case
    if (prefix.toLowerCase().startsWith("xml")) {
        return "Namespace prefixes cannot begin with " +
                "\"xml\" in any combination of case";
    }

And perhaps add in its place a check that user code isn't defining "xml" or "xmlns".

[michael-o]

I would definitively hinder a client creating such namespace prefixes but would not fail if a file with such prefixes is read.

[hunterhacker]

Seems to me like the spec is written this way ("MUST NOT fail") so that when a new xmlfoo prefix comes out via the standards process, they want tools like JDOM to not reject it. So we should probably accept it, right? A warning or something would be nice, but there's no real vehicle for that that comes to mind.

[rolfl]

There is a vehicle for checking, or not checking the XML content as it is being loaded through a 'trusted' parser, but, even the unchecked version still will fail because the namespace will fail to be created.

I think the right solution here may be to just remove the checking, and document, document, and document it.

As soon as you say that JDOM should be able to load such files, it is only logical that it should be able to edit, and create them too. JDOM is about amking the possible things 'easy'.... but, this feels like a long enough piece of rope that it could backfire .... JDOM is not the only code that will fail with such things, surely? Then it will become JDOM's fault for letting the user create broken documents.... hmmm.... rock, and hard place.

Putting system-wide configuration options (like System properties, etc.) is not a viable solution, and Namespace class is a static one.

At this point in time we either change nothing (keep the fail), or change everything (not restrict anything). Those are the only two alternatives. I can't see a compromise. Am I missing something?

[hunterhacker]

The spec clearly says we have to let it pass, so we should do that, no restriction.

[rolfl]

Right, I agree here... I think it is the consensus. I have some other items backlogged and will push them through 'real soon'.

[michael-o]

I am not really familiar with JDOM but isn't is possible to control the creation of such namespace prefixes with a properties Map?

[rolfl]

So, I am working on this right now. Question, from the specification: http://www.w3.org/TR/REC-xml-names/#xmlReserved

The prefix xml is by definition bound to the namespace name 
http://www.w3.org/XML/1998/namespace. It MAY, but need not, be declared, and 
MUST NOT be bound to any other namespace name. Other prefixes MUST NOT 
be bound to this namespace name, and it MUST NOT be declared as the default
 namespace.

The prefix xmlns is used only to declare namespace bindings and is by definition 
bound to the namespace name http://www.w3.org/2000/xmlns/. It MUST NOT be 
declared . Other prefixes MUST NOT be bound to this namespace name, and it 
MUST NOT be declared as the default namespace. Element names MUST NOT 
have the prefix xmlns.

All other prefixes beginning with the three-letter sequence x, m, l, in any case 
combination, are reserved. This means that:

 -   users SHOULD NOT use them except as defined by later specifications

 -   processors MUST NOT treat them as fatal errors.

Question, is the prefix 'XML' (uppercase), or 'XmL', or 'XmLnS' valid? (i.e. mixed case versions of the reserved prefixes)

I am working on the literal interpretation that Xml and XMLns, etc. are 'OK'

[michael-o]

The first two paragraphs do not strictly require case-insensitivity but see this (http://www.w3.org/TR/2000/WD-xml-2e-20000814#dt-name), defintion for Name.

[rolfl]

That name is somewhat different to the prefix, but it still holds some value. That name is for Element tag-names (what comes after the colon). Also, it seems to be OK to actually use 'xml' as the Element name, so I am not sure how it all applies.

The following document validates 'good' using xmllint on my linux box:

<xMl:xml xmlns:xMl="MyURI" xml="1"/>

[michael-o]

Rolf, Name refers to xs:Name and a namespace prefix to xs:NCName. I think, you misunderstood me.

Element names are not discussed in this ticket, namespace prefixes only.

[hunterhacker]

My reading is that we need to allow other character cases. They're reserved and people should not use them, but the spec says we're not allowed to treat them as fatal errors.

[rolfl]

OK, that's where I have things in the currently committed code here. It accepts:

<xMl:xml xmlns:xMl="MyURI" xml="1"/>

and I think that's OK, and it will stay that way. ;-) Just sorting out some merges, etc. Release 2.0.6 real soon now.

[rolfl]

Code will now validate xml-prefixed values in any combinations of text/case, except the two prefixes 'xml' and 'xmlns' (both in lower case) which have special handling.