> does anybody know how and when to get the opportunity to play with > ECMAScript for XML (E4X) in a browser?
It's about to be turned on for 1.8a6. It will be enabled by default in XUL scripts and in JS XPCOM components. To enable it in HTML script tags, you'll have to specify type="application/x-javascript;e4x=1" or type="text/javascript;e4x=1" in the tag.
>> does anybody know how and when to get the opportunity to play with >> ECMAScript for XML (E4X) in a browser?
> It's about to be turned on for 1.8a6. It will be enabled by default in > XUL scripts and in JS XPCOM components. To enable it in HTML script > tags, you'll have to specify type="application/x-javascript;e4x=1" or > type="text/javascript;e4x=1" in the tag.
> /be
Brendan, Can you tell what is the current status of Javascript 2.0 ? Thanks in advance for any answer.
>> does anybody know how and when to get the opportunity to play with >> ECMAScript for XML (E4X) in a browser?
> It's about to be turned on for 1.8a6. It will be enabled by default in > XUL scripts and in JS XPCOM components. To enable it in HTML script > tags, you'll have to specify type="application/x-javascript;e4x=1" or > type="text/javascript;e4x=1" in the tag.
> /be
Hi Brendan,
Though terrified, I might as well make the best of it.
1. Is the version number going to change to 1.6 or similar?
2. How can I get the current SM code for E4X? Is it in the nightly tarballs?
>> To enable it in HTML script tags, you'll have to specify >> type="application/x-javascript;e4x=1" or type="text/javascript;e4x=1" >> in the tag.
>> /be
> Hi Brendan,
> Though terrified, I might as well make the best of it.
Why terrified? E4X won't hurt ya! ;-)
> 1. Is the version number going to change to 1.6 or similar?
No. E4X is orthogonal to the JS version. The way to select it is with the MIME type. The language= attribute has been deprecated by HTML 4.x for a while now (for all that's worth ;-).
> 2. How can I get the current SM code for E4X? Is it in the nightly > tarballs?
It's in the CVS trunk so any release off the trunk (nightly builds, didn't know we released tarballs) will have it.
>>> To enable it in HTML script tags, you'll have to specify >>> type="application/x-javascript;e4x=1" or type="text/javascript;e4x=1" >>> in the tag.
>>> /be
>> Hi Brendan,
>> Though terrified, I might as well make the best of it.
> Why terrified? E4X won't hurt ya! ;-)
<rant> Ain't broke, don't fix. It's not hard to write a fault-tolerant XML parser in JS, and how do I know that the choices made in designing E4X are going to be the ones I desire or expect? See earlier discussion about JS2.0 for inherent reticence to embrace changes to languages that underpin complex systems.
E4X appears to take a vocabulary (E) and force it onto an object model (X). I would have been a lot happier if the designers had started with a clear data processing objective, and invented a vocabulary to match. What we have now looks a lot like a camel.
var twoemployees = e.employee.(@id == 0 || @id == 1); for each (var p in e..employee) { ... }
What's this @ stuff? Perl is the language of obscure punctuation, not JavaScript! I just know that some newbie is going to look at that and think that they can get away with that sort of syntax for any JS object, then call me and wonder why it doesn't work. Then they'll ask how many dots are supposed to be between e and employee. And I won't have a clue?
I wish that the E4X designers had put compactness of syntax secondary to clarity of purpose. </rant>
>> 1. Is the version number going to change to 1.6 or similar?
> No. E4X is orthogonal to the JS version. The way to select it is with > the MIME type. The language= attribute has been deprecated by HTML 4.x > for a while now (for all that's worth ;-).
There have been enough changes since 1.5rc6a that you might consider a new version number. The ATLINE option is new, and XML hooks are pervasive.
I'm reading through jsxml.c, and notice that you sensibly observe that > escaping isn't necessary. Can you explain the testcase
It will be interesting to figure out how namespaces work. Do namespaces go into the global string hash table?
>> 2. How can I get the current SM code for E4X? Is it in the nightly >> tarballs?
> It's in the CVS trunk so any release off the trunk (nightly builds, > didn't know we released tarballs) will have it.
Shanti Rao wrote: > <rant> > Ain't broke, don't fix. It's not hard to write a fault-tolerant XML > parser in JS, and how do I know that the choices made in designing E4X > are going to be the ones I desire or expect?
E4X folks designed (and hacked, a lot -- one prototype based on Rhino predates the standard, woohoo!) with XQuery and other XML standards in mind. They separated data model from syntax, and built on xml-infoset (errata notwithstanding; the spec's being fixed for ISO).
> See earlier discussion > about JS2.0 for inherent reticence to embrace changes to languages that > underpin complex systems.
That's a bit to general to work with. :-/
> E4X appears to take a vocabulary (E) and force it onto an object model > (X). I would have been a lot happier if the designers had started with a > clear data processing objective, and invented a vocabulary to match.
I'm pretty sure they did that, but I wasn't around, so I'll defer to others who may know better.
> What we have now looks a lot like a camel.
Camels are useful, even if Ugly. You know you're dangerously close to insulting Perl here... ;-)
> var twoemployees = e.employee.(@id == 0 || @id == 1); > for each (var p in e..employee) { ... }
> What's this @ stuff?
Attributes are in a separate namespace with a distinct operator prefixing literal name uses. This is based directly on XQuery, IIRC.
> Perl is the language of obscure punctuation,
You're now over the edge.
Look, @attrname is not obscure, and if you don't like at-signs, think of them as "at"tribute signs. JS+E4X is not Perl by a long shot, but I'm not about to join you in knocking Perl. And I don't mean Perl 6, either, I mean Perl 5, hack that it is. Hacks can be useful.
> I just know that some newbie is going to look at that and > think that they can get away with that sort of syntax for any JS object, > then call me and wonder why it doesn't work.
They'll get a clear diagnostic. You can't write 42() in JS and have it evaluate to 42, either -- why aren't newbies confused by that? Newbies don't just throw in @ because it looks cool (or you have a lower grade of newbie than you should tolerate).
> Then they'll ask how many > dots are supposed to be between e and employee. And I won't have a clue?
... is used in C-like languages, but maybe three times is the charm.
> I wish that the E4X designers had put compactness of syntax secondary to > clarity of purpose.
In a few places, I agree with you, but JS already loses to Python (never mind Perl) in the estimation of people I respect because of JS's C/Java verbosity, both for block structure and control keywords, and in the lower-level sub-grammars. And Python is winning while we all wait for Perl 6.
So there has to be a fine balance between conciseness and readability, and I think E4X gets it mostly right.
> There have been enough changes since 1.5rc6a that you might consider a > new version number. The ATLINE option is new, and XML hooks are pervasive.
JSOPTION_ATLINE is a tiny API option for XUL preprocessing, it hardly merits a version trip.
The XML hooks are indeed pervasive, but that's an implementation detail. The language doesn't change unless you both compile-time enable *and* run-time enable E4X. The version number is for the language, not for the implementation.
> I'm reading through jsxml.c, and notice that you sensibly observe that > > escaping isn't necessary. Can you explain the testcase
What testcase?
> It will be interesting to figure out how namespaces work. Do namespaces > go into the global string hash table?
What global string hash table? I think you are mixing up implementation details, but if you have a language question about namespaces, I can help. E4X namespaces are being made consistent with namespaces in Edition 4 (JS2, ActionScript 2).
> don't just throw in @ because it looks cool (or you have a lower grade > of newbie than you should tolerate).
Well, my newbies are corporate IT-types. Visual Basic and JavaScript are what they're familiar with, and they find Python scary and UNIX-centric (though it's getting better) and Perl unreadable.
Perhaps it's inevetible that a language aquires complexity until it's sufficient complex that an opportunity for a new language is created?
> Perhaps it's inevetible that a language aquires complexity until it's > sufficient complex that an opportunity for a new language is created?
Possibly, and there should be, and will be, new and better languages (already are, but since worse is better, many "better" ones lost in a Darwinian who's-on-first contest).
But I'd say JS+E4X is ahead of the curve, judging from the rise of XML and the E4X envy seen among the Python and Ruby folks ;-). And the complexity is not terrible, but I agree it could be simpler. Adding namespaces is a big complexity increase, and all evidence we and others (Micah Dubinko, e.g.) have say that namespaces are the most error-prone part of practical XML.
It counts one more than the greatest atom index of all declared global variables and regular expressions in the script. It's used for the fast global optimization (see bug 169559, fixed, and follow-on bug 276249).
> 2. Do you recommend editing jsconfig.h to set JS_HAS_XML_SUPPORT = 1?
It's on in the CVS trunk, so I should think so! ;-)
Brendan Eich wrote: > <script type="text/javascript;e4x=1"> > var x = <t><u id="1">one</u><u id="2">two</u><u id="3">three</u></t>; > alert(x.toXMLString()); > </script>
What is happening if I have several script elements in a HTML document, some saying <script type="text/javascript;e4x=1"> some <script type="text/javascript"> will they share variables? It seems they do here with a Mozilla nightly some days old.
It also seems typeof XML is function event in <script type="text/javascript"> blocks. Does that mean it is possible to construct native XML object with new XML() in <script type="text/javascript"> blocks, only parsing of XML "literals" wouldn't work there?
As for that <script type="text/javascript;e4x=1"> Content-Type notation, is that something that Mozilla has "invented" to enable web developers to distinguish between "normal" JavaScript and E4X enabled JavaScript or is that something the participants in the ECMA working group have agreed on? Unfortunately Opera browers for instance try to consume such <script type="text/javascript;e4x=1"> and then obviously throw syntax errors.
Well, I've compiled it, and it seems to work. It even seems to coexist with my existing XML classes. If anyone wants, there's a precompiled Windows binary at www.jsdb.org.
>> <script type="text/javascript;e4x=1"> >> var x = <t><u id="1">one</u><u id="2">two</u><u id="3">three</u></t>; >> alert(x.toXMLString()); >> </script>
> What is happening if I have several script elements in a HTML document, > some saying > <script type="text/javascript;e4x=1"> > some > <script type="text/javascript"> > will they share variables? It seems they do here with a Mozilla nightly > some days old.
Sure, scripts in the same document all share the same global object, namely the window object.
This doesn't change, nor should it.
What does change, and it's big in terms of web compatibility, is that the old-as-JS "script hiding hack" for hiding inline script content from browsers that don't understand JS (are there any, nowadays?):
<script language="JavaScript"> <!-- hide from old browsers function foo() {...} // etc. // done hiding from old browsers --> </script>
does not work in <script type="text/javascript; e4x=1">...</script> content, because E4X says that <!-- starts an XML comment.
> It also seems > typeof XML > is function event in > <script type="text/javascript"> > blocks. Does that mean it is possible to construct native XML object > with new XML() in <script type="text/javascript"> blocks, only parsing > of XML "literals" wouldn't work there?
Yes. I didn't want to add unnecessary runtime checks, and reckoned that it's better to define XML unconditionally. This smoked out some const XML = ... cases in Firefox help, but they turned out to be dead consts, and they were removed.
If predefining XML, XMLList, Namespace, QName, and isXMLName breaks compatibility too much, we can add more runtime option-checking. But I want to find out, so getting this level of support into 1.8a6 should, and getting that alpha wide distribution and testing among hackers who can report good bugs, will help.
> As for that <script type="text/javascript;e4x=1"> Content-Type notation, > is that something that Mozilla has "invented" to enable web developers > to distinguish between "normal" JavaScript and E4X enabled JavaScript or > is that something the participants in the ECMA working group have agreed > on?
It's Mozilla-only, and E4X implemented in SpiderMonkey is the first such browser implementation that I know of. Someone tell me if there's another browser that does E4X already.
I'm trying to get the ECMA TG1 group to help the w3c do the right thing with the content types that the w3c has made up without bothering to register them with the IETF (nowadays, with the IANA -- see http://www.iana.org/).
> Unfortunately Opera browers for instance try to consume such <script > type="text/javascript;e4x=1"> and then obviously throw syntax errors.
That is unfortunate. Does Opera do anything with any version parameter (or with "JavaScript1.2" as the language attribute's value, if type is not used)? We could make a new version of the language, but if it doesn't help hide E4X content from other browsers, then there's no point.
As you'd expect from past history with other JS innovations (if anyone recalls the JS1.2 and ECMA Editions 1-3 rollouts), attempts to use E4X on the web will require good browser sniffing and content selection on the server side, not just good script tag version/option control in static content.
In the mean while, E4X is good for use in private pages, and especially in JS XPCOM components and in XUL. Even without the DOM two-way binding that remains to be done, it's handy.
Brendan Eich wrote: >> Unfortunately Opera browers for instance try to consume such <script >> type="text/javascript;e4x=1"> and then obviously throw syntax errors.
> That is unfortunate. Does Opera do anything with any version parameter > (or with "JavaScript1.2" as the language attribute's value, if type is > not used)? We could make a new version of the language, but if it > doesn't help hide E4X content from other browsers, then there's no point.
neither Opera or Konqueror respect language version specified by the |language| or |type| attributes of the script tag. like mikey, they will attempt to execute anything.
> It counts one more than the greatest atom index of all declared global > variables and regular expressions in the script. It's used for the fast > global optimization (see bug 169559, fixed, and follow-on bug 276249).
It looks like if you want to serialize a script, you're limited to 65535 global objects? I'm noticing that js_XDRScript() only keeps 16 bits at jsscript.c#429. Does anyone even use that feature anymore? Is the iPlanet server still in print?
Brendan Eich wrote: >> It also seems >> typeof XML >> is function event in >> <script type="text/javascript"> >> blocks. Does that mean it is possible to construct native XML object >> with new XML() in <script type="text/javascript"> blocks, only parsing >> of XML "literals" wouldn't work there?
> Yes.
Should trying to parse XML source from string with new XML('<root>content</root>') work then in <script type="text/javascript" blocks? It seems it doesn't, the XML function is available but calling it with some well-formed XML causes an error, test case is here <http://home.arcor.de/martin.honnen/javascript/200501/test2005010703.html> Error in the JavaScript console is
Shanti Rao wrote: > It looks like if you want to serialize a script, you're limited to 65535 > global objects? I'm noticing that js_XDRScript() only keeps 16 bits at > jsscript.c#429. Does anyone even use that feature anymore? Is the > iPlanet server still in print?
Yes, XDR is used every time you restart Firefox, Thunderbird, Mozilla, etc. as part of XUL FastLoad.
No, there's no new limit here: atom indexes stored as immediate operands in bytecode were always two bytes, so always limited to maximum value of 65535.
> Should trying to parse XML source from string with > new XML('<root>content</root>') > work then in <script type="text/javascript" blocks?
No, you need to enable e4x=1. Again, the XML constructor is exposed to catch name collisions, not to be useful without the option parameter in the MIME type.
If this seems wrong, let me know what's less wrong: (1) turning off XML, etc., in the absence of e4x=1; (2) magically turning E4X support on in spite of no e4x=1 when a script calls XML, or Namespace, or ....
I think (2) is crazy. (1) is do-able, but again, I wanted to smoke out name collisions during 1.8a6.
>> Should trying to parse XML source from string with >> new XML('<root>content</root>') >> work then in <script type="text/javascript" blocks?
> No, you need to enable e4x=1. Again, the XML constructor is exposed to > catch name collisions, not to be useful without the option parameter in > the MIME type.
> neither Opera or Konqueror respect language version specified by the > |language| or |type| attributes of the script tag. like mikey, they will > attempt to execute anything.
Firefox 1.0 WinXPSP2 Executes language attribute version up to 1.5 Executes if type="text/javascript;version=xx" up to 1.5 Executes if type="text/javascript;e4x=1" js language == 1.5 js type == 1.5 e4x == 1
MSIE6 WinXPSP2 Executes language attribute version up to 1.3 Executes if type="text/javascript", ignores if version specified Ignores if type="text/javascript;e4x=1" js language == 1.3 js type == default e4x == undefined
Opera 7.54 WinXPSP2 Executes language attribute version up to 1.5 Executes if type="text/javascript;version=xx" up to anything Executes if type="text/javascript;e4x=1" js language == 1.5 js type == 99.99 e4x == 1
Konqueror 3.2.1 SuSe 9.1 Executes language attribute version up to anything Executes if type="text/javascript;version=xx" up to anything Executes if type="text/javascript;e4x=1" js language == 99.99 js type == 99.99 e4x == 1
Brendan Eich wrote: >In the mean while, E4X is good for use in private pages, and >especially in JS XPCOM components and in XUL. Even without binding >the DOM two-way that remains to be done, it's handy.
Is E4X supposed to work in XUL scripts now? I tried to load the following XUL file, and it didn't work (I tried it without type attribute and from an extension; tested with 20040107 Firefox build). Your example above (script in an HTML file) worked...
Nick
The XUL file: ---- <window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"> <script type="application/x-javascript;e4x=1"><![CDATA[ var x = <t><u id="1">one</u><u id="2">two</u><u id="3">three</u></t>; alert(x.toXMLString()); ]]></script> </window> ----
|
