On 6/2/06, John Kaputin <[EMAIL PROTECTED]> wrote:
The ctor for QName specifies a String argument for local part and the Javadoc (J2EE 1.4, J2SE 1.5) does not specify any special handling beyond null and empty string. The NCName class has the appropriate ctor validation.
Which ever JSR created QName in the first place might have taken the decision not to validate because of the potential performance overhead. QName could check there's no prefix in the localpart parm but then what about other validation checks on the localpart to make sure it conforms to the QName part of the XML datatypes spec [1] errr which would be to check the localpart is a valid NCName.
I'm just pointing out that NCName is inconsistent with QName w.r.t. validation. There must have been a decision to exclude (localpart) NCName validation from QName and performance may have been an element of the decision (my supposition). So if we have to cope with QNames potentially holding an invalid NCName as their localpart it makes sense (to me) that we should be consistent with that and use the same logic to cope with NCNames being invalid. I also had the impression that the more invalid data we retain, the better the validation error message can be. Running the validator over a DescriptionElement that contains a null where it should contain an NCName object can't indicate what the input text to the NCName was. If an invalid NCName is present then the validator can indicate the cause by outputting the input to the NCName ctor. [1] http://www.w3.org/TR/xmlschema-2/#QName Regards, Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
