Closed Bug 490758 Opened 15 years ago Closed 15 years ago

QName constructor allows unqualified names.

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: sephr, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.10) Gecko/2009042523 Ubuntu/9.04 (jaunty) Firefox/3.0.10 GTB5
Build Identifier: 

The QName constructor allows unqualified names. For example, new QName("~!@#$\n%^") doesn't throw any errors. A viable fix could be to throw a SyntaxError or ignore the name when QName isn't passed a qualified name.
The similar Namespace constructor just ignores the name and makes the prefix property be undefined.

Reproducible: Always

Steps to Reproduce:
new QName([any namespace, ] "any unqualified name")
Actual Results:  
No errors and localName is set.

Expected Results:  
SyntaxError or localName is undefined.
Blocks: e4x
(In reply to comment #0)
> The similar Namespace constructor just ignores the name and makes the prefix
property be undefined.

Oops, I mean the Namespace constructor, when passed *an invalid prefix* just ignores it and makes the prefix
property be undefined.
This all was implemented per ECMA-357. What part of the spec are we violating?

13.3.2 The QName Constructor
Syntax
  new QName ( Name )
  new QName ( Namespace , Name )
...
Semantics
1. If (Type(Name) is Object and Name.[[Class]] == "QName")
a. If (Namespace is not specified), return a copy of Name
b. Else let Name = Name.localName
2. Let Name = ToString(Name)
3. If (Namespace is undefined or not specified)
a. If Name = "*"
i. Let Namespace = null
b. Else
i. Let Namespace = GetDefaultNamespace()
4. Let q be a new QName with q.localName = Name
5. If Namespace == null
a. Let q.uri = null NOTE: implementations that preserve prefixes in qualified names may also set q.[[Prefix]] to undefined
6. Else
a. Let Namespace be a new Namespace created as if by calling the constructor new Namespace(Namespace)
b. Let q.uri = Namespace.uri NOTE: implementations that preserve prefixes in qualified names may also set q.[[Prefix]] to Namespace.prefix
7. Return q

/be
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
I'm sorry, I thought that it said that QName can only be a qualified name, but I misread it.
Isn't it better to have a valid name for localName.
if correct, can we rise at E4X spec meeting?
No one is maintaining the E4X spec, ECMA-357, at present. You could mail es-discuss@mozilla.org about this particular issue, but the real issue is the lack of maintenance. Raising that might help take the temperature of the folks on that list regarding E4X, but you might find sentiment mixed.

IIRC, the idea behind QName not validating is that script authors should choose to validate, if they care, using isXMLName. This leaves policy in the hands of the authors. It's debateable for sure, but it is tenable IMHO.

We (Mozilla folks with commit access, whoever we may be) are not likely to change SpiderMonkey to deviate from the E4X spec, so your best bet is to find people, emphatically including Ecma members active in TC39, who might actually agree to change the spec, *and* do the non-trivial amount of work to make the changes and create a new edition of the standard.

/be
The only other widely distributed E4X implementation (Rhino does not count, since Sun removes E4X when distributing Rhino behind the JSR-223 interface as part of J2SE or whatever it's called) is Flash ActionScript. I would bet it follows the spec here too. Again hard to justify deviating.

/be
You need to log in before you can comment on or make changes to this bug.