Slashdot Mirror

I got a 404. Shit! My DNS has been poisoned!

... it ended up with a 404 page. I thought it was a blip on their server, but now I see they retracted the post.

They fail. If they've removed it with no intention of making it available again it should be 410 Gone, not 404 Not Found. Am I the only person who reads the HTTP spec? It's not exactly hard to understand...

... it ended up with a 404 page. I thought it was a blip on their server, but now I see they retracted the post.

They fail. If they've removed it with no intention of making it available again it should be 410 Gone, not 404 Not Found. Am I the only person who reads the HTTP spec? It's not exactly hard to understand...

• studiVZ's homepage is linked to just over 1000 lines of CSS, while Facebook's homepage includes over 2000.
• studiVZ validates as valid XHTML 1.0 Transitional, Facebook fails trying to call itself XHTML 1.0 Strict.

If the markup is this different, imagine how different the underlining server scripts probably could be. Facebook appears to be powered by PHP (/*.php) but studiVZ is hiding extension and doesn't expose its PHP if that's what it is even using.

• studiVZ's homepage is linked to just over 1000 lines of CSS, while Facebook's homepage includes over 2000.
• studiVZ validates as valid XHTML 1.0 Transitional, Facebook fails trying to call itself XHTML 1.0 Strict.

If the markup is this different, imagine how different the underlining server scripts probably could be. Facebook appears to be powered by PHP (/*.php) but studiVZ is hiding extension and doesn't expose its PHP if that's what it is even using.

Try XForms. It's what web forms wanted to be when they grew up. Validation, direct editing of data, creates and removes form elements dynamically, abstract input types, and much more.

Can't the World Wide Web Consortium take over the job? Of course, Verisign will be all against it as it breaks their monopoly ...

At the risk of losing karma:

My sig is more hate toward the moderators...

Love them or hate them, moderators and meta-moderators are part of the system. If all you are concerned about is karma, then you will have to weigh you desire to post against your fear of loosing karma points. My suggestion is to say what you want intelligently and damn whether it is popular. Popular speech is boring.

As to your post above:

...it's a site developer's responsibility to make their web site work in all browsers in common usage, not just the ones they feel like.

I must disagree. If it exists, it is a developer's responsibility to code to a set of standards. It is a site and browser developer's responsibility to code to a set of standards.

XML tags are lowercase.

Wrong. XML is case-sensitive, not lowercase. XHTML uses lowercase XML elements, but in general XML elements are not lowercase only.

>That's the stupidest statement I've heard on Slashdot today. "Once the horrendously expensive and unprofitable part is done, it costs nothing!"

So, I suppose, if you were legally allowed to operate it, you'd be the one person on the board OPPOSED to building a money printing machine?

Yes, there's hard work involved, and some expense too. That's why they're a company. They do that hard work in exchange for your money (novel concept).

However, unlike a case where you're selling a good, in that you run out of those goods and continually have further expenses, usenet is a service, and apart from the cost of improving said service, it is a "license to print money" in that after the initial investment, you reap near 100% net profit margin. Trust me, most companies *like* that kind of business.

>How do you propose the data gets on their network genius?

Well, thank you for attesting to my title, humble normal. I believe the method is well documented in RFC 977. I would suggest you read it.

>The amount of data they would need to move to satisfy a tiny niche audience is so astronomically out of proportion to the subscription fees that tiny userbase providers they're more than happy to kick you to the curb.

That might be so, and as such, the provider will need to balance the cost of the money printing machine vs. how much money can it print each day. If you invest $1 million dollars in a money printing machine, but find out it can only print $100 a day, you might need to reconsider the investment

However, for a particularly large ISP (such as these) the bandwidth cost is negligible (clearly you live in a dreamworld where large national ISPs *don't* have several gigabit internet links). The only particularly large costs involved would be paying administrators, paying for equipment, and paying for electricity.

The fact is, not running the NNTP server has costs associated with it as well. Those dedicated to usenet binaries will use alternative services, going across your expensive internet links to download the same multi-gigabyte files hundreds, thousands, if not more times. That activity, though, is what I expect you're missing in your equation.

>And who can blame them?

I certainly don't. My ISP doesn't offer particularly good NNTP service. So, I have an unlimited NNTP service, and generally download 500 GB monthly from them. Speaking with others, there's probably a good solid 1,000+ of us doing this on this ISP. I suppose 500 TB of transit monthly is cheaper than a 100 mbit link for usenet for our ISP, and that's fine with us.

However, this ISP is smaller (only serves Canada). I'd be very surprised if a National US ISP really is finding 5 PB of traffic a cheaper deal than providing NNTP. But hey, each to their own.

XML is a system of grammar that is used to create defined formats.

...made for people who slept through compiler courses.

For the record, there is nothing I like more than writing custom parsers its hella fun! That being said; I have things to do other than watch Matlock and write parsers for no good reason (it's like knitting for DPD-11 crowd).

... XML provides ridiculously complex, stupidly designed means to define a syntax, and absolutely nothing to define semantics, so you still have to either document it or, more likely, provide an implementation.

Your argument about implementation is a red herring. If by semantics you are refering to application-level semantics then yes you have to provide an implementation. Show me a file-oriented data storage method that automatically handles application level semantics. You can't because application level semantics are always handled by the implementation. If you write a custom format/parser you can deal with these issues during the parsing phase, but it doesn't remove the fact that this is an implementation level feature.

Guess what? The syntax is such a microscopic part of your task, the amount of work you have just placed into your reference implementation of semantics is multiple orders of magnitude higher than whatever you "saved" by not implementing syntax parser from scratch, leave alone implemented it using any tools that existed long before XML was introduced. The problem is, people who "learn XML" never learn how dead simple parsing in general is, so they use those "frameworks" and "tools" to save what otherwise would be literally seconds of their mental work.

So your suggestion is that I should develop custom file formats and parsers for every single application I write?!?!? That sounds great! I think I'll do everything from now on in custom packed binary! Who needs architecture independence?! Who needs the ability to share or re-use data easily!?! Who needs the ability to read their data outside of the framework it was developed in!?! And what if the specs change? I get to throw out all my existing data and start over again... or get the honor of writting a custom conversion script!!! I'm glad you've made me see the light!

I am not against simplifying further tasks that are already simple if it serves any valid purpose. The problem with XML, it does not really simplify anything, it provides ridiculously amateurish solution for a common easy problem without even a slightest attempt to help with truly complex part of work.

Yes you are right; 1) preparing an ad-hoc representation of my document, 2) automatically generating a schema from it, 3) being able to read/validate instances of the document in 3 line of code is horribly complex!! God forbid the only thing I have to do to get data into/out of my program is check the correctness of the data. God forbid that I don't have to write/debug/maintain a custom parser/format because I'm using one based on standards!

Words "XML", "abstract" and "semantic" do not belong in the same phrase -- XML is developed at the level of a second-year CS student who managed to completely miss what "abstract" and "semantics" mean. It's not "abstract", it's artificial and irrelevant. The only value of XML is the fact that it's some standard, however this does not change the fact that it's nearly the worst possible solution for any imaginable problem.

You fail to understand the big picture and the larger set of interactions the XML family is meant to address W3C Semantic Web Activity.

Have you read anything I wrote? [...]

Unfortunately... I think it's time you had your glass of warm milk and went to bed, you need to be up to greet the mailman at 6am and complain about the adverts that keep showing up in your mailbox.

If you are interested look there about multiple backgrounds: http://www.w3.org/TR/css3-background/#layering
(basically, allows multiple backgrounds without xxx amount of wrappers)

The development of the Efficient XML Interchange (EXI) format was guided by five design principles, namely, the format had to be general, minimal, efficient, flexible, and interoperable. The format satisfies these prerequisites, achieving generality, flexibility, and performance while at the same time keeping complexity in check.

Many of the concepts employed by the EXI format are applicable to the encoding of arbitrary languages that can be described by a grammar. Even though EXI utilizes schema information to improve compactness and processing efficiency, it does not depend on accurate, complete or current schemas to work.

XML is crappy format

That statement underlines most people's myopic vision of the XML family of technologies. XML is not a format it is a family of technologies based around a common grammar.

XML is not a bucket.
It is not a passive container for data.
It is a transformable semantic graph.

The heart and sole of XML is XLST it serves as a common 'glue' that allows the transformation between the various standardized 'languages' XML, XHTML, XLST, XSL-FO, SVG, RDF, RSS, etc...

Example; the same XML document (lets say it represents rows in a database) can be transformed into a web page, pdf file, visual graph, rss feed, directed graph, or [insert non-XML text based output of choice]. More importantly the transformation can take place on the client side of a transaction effectively decoupling content and representation.

That being said, I completely agree that XML is over-kill for simple fixed message passing. But, then again simple fixed format message passing isn't what XML was really designed for :-) XML was designed for situations where the representation needs of the client are unknown and/or dynamic.

--
If you don't know XSLT you don't know XML

XML is crappy format

That statement underlines most people's myopic vision of the XML family of technologies. XML is not a format it is a family of technologies based around a common grammar.

XML is not a bucket.
It is not a passive container for data.
It is a transformable semantic graph.

The heart and sole of XML is XLST it serves as a common 'glue' that allows the transformation between the various standardized 'languages' XML, XHTML, XLST, XSL-FO, SVG, RDF, RSS, etc...

Example; the same XML document (lets say it represents rows in a database) can be transformed into a web page, pdf file, visual graph, rss feed, directed graph, or [insert non-XML text based output of choice]. More importantly the transformation can take place on the client side of a transaction effectively decoupling content and representation.

That being said, I completely agree that XML is over-kill for simple fixed message passing. But, then again simple fixed format message passing isn't what XML was really designed for :-) XML was designed for situations where the representation needs of the client are unknown and/or dynamic.

--
If you don't know XSLT you don't know XML

XML is crappy format

That statement underlines most people's myopic vision of the XML family of technologies. XML is not a format it is a family of technologies based around a common grammar.

XML is not a bucket.
It is not a passive container for data.
It is a transformable semantic graph.

The heart and sole of XML is XLST it serves as a common 'glue' that allows the transformation between the various standardized 'languages' XML, XHTML, XLST, XSL-FO, SVG, RDF, RSS, etc...

Example; the same XML document (lets say it represents rows in a database) can be transformed into a web page, pdf file, visual graph, rss feed, directed graph, or [insert non-XML text based output of choice]. More importantly the transformation can take place on the client side of a transaction effectively decoupling content and representation.

That being said, I completely agree that XML is over-kill for simple fixed message passing. But, then again simple fixed format message passing isn't what XML was really designed for :-) XML was designed for situations where the representation needs of the client are unknown and/or dynamic.

--
If you don't know XSLT you don't know XML

XML is crappy format

That statement underlines most people's myopic vision of the XML family of technologies. XML is not a format it is a family of technologies based around a common grammar.

XML is not a bucket.
It is not a passive container for data.
It is a transformable semantic graph.

The heart and sole of XML is XLST it serves as a common 'glue' that allows the transformation between the various standardized 'languages' XML, XHTML, XLST, XSL-FO, SVG, RDF, RSS, etc...

Example; the same XML document (lets say it represents rows in a database) can be transformed into a web page, pdf file, visual graph, rss feed, directed graph, or [insert non-XML text based output of choice]. More importantly the transformation can take place on the client side of a transaction effectively decoupling content and representation.

That being said, I completely agree that XML is over-kill for simple fixed message passing. But, then again simple fixed format message passing isn't what XML was really designed for :-) XML was designed for situations where the representation needs of the client are unknown and/or dynamic.

--
If you don't know XSLT you don't know XML

XML is crappy format

That statement underlines most people's myopic vision of the XML family of technologies. XML is not a format it is a family of technologies based around a common grammar.

XML is not a bucket.
It is not a passive container for data.
It is a transformable semantic graph.

The heart and sole of XML is XLST it serves as a common 'glue' that allows the transformation between the various standardized 'languages' XML, XHTML, XLST, XSL-FO, SVG, RDF, RSS, etc...

Example; the same XML document (lets say it represents rows in a database) can be transformed into a web page, pdf file, visual graph, rss feed, directed graph, or [insert non-XML text based output of choice]. More importantly the transformation can take place on the client side of a transaction effectively decoupling content and representation.

That being said, I completely agree that XML is over-kill for simple fixed message passing. But, then again simple fixed format message passing isn't what XML was really designed for :-) XML was designed for situations where the representation needs of the client are unknown and/or dynamic.

--
If you don't know XSLT you don't know XML

XML is crappy format

That statement underlines most people's myopic vision of the XML family of technologies. XML is not a format it is a family of technologies based around a common grammar.

XML is not a bucket.
It is not a passive container for data.
It is a transformable semantic graph.

The heart and sole of XML is XLST it serves as a common 'glue' that allows the transformation between the various standardized 'languages' XML, XHTML, XLST, XSL-FO, SVG, RDF, RSS, etc...

Example; the same XML document (lets say it represents rows in a database) can be transformed into a web page, pdf file, visual graph, rss feed, directed graph, or [insert non-XML text based output of choice]. More importantly the transformation can take place on the client side of a transaction effectively decoupling content and representation.

That being said, I completely agree that XML is over-kill for simple fixed message passing. But, then again simple fixed format message passing isn't what XML was really designed for :-) XML was designed for situations where the representation needs of the client are unknown and/or dynamic.

--
If you don't know XSLT you don't know XML

XML is crappy format

That statement underlines most people's myopic vision of the XML family of technologies. XML is not a format it is a family of technologies based around a common grammar.

XML is not a bucket.
It is not a passive container for data.
It is a transformable semantic graph.

The heart and sole of XML is XLST it serves as a common 'glue' that allows the transformation between the various standardized 'languages' XML, XHTML, XLST, XSL-FO, SVG, RDF, RSS, etc...

Example; the same XML document (lets say it represents rows in a database) can be transformed into a web page, pdf file, visual graph, rss feed, directed graph, or [insert non-XML text based output of choice]. More importantly the transformation can take place on the client side of a transaction effectively decoupling content and representation.

That being said, I completely agree that XML is over-kill for simple fixed message passing. But, then again simple fixed format message passing isn't what XML was really designed for :-) XML was designed for situations where the representation needs of the client are unknown and/or dynamic.

--
If you don't know XSLT you don't know XML

Maybe they worked fast but in the wrong direction. They focused on display without enhancing the form components. I remember that 7 years ago I wanted to implement a simple combo box (select + edit new value) and had no choice. Now is still the same apart from libraries that are doing workarounds.

Even now looking at the "Web 2 revolution" they are still focusing on stylesheets for display instead of looking for standards for interaction with the users and comunication with the servers.

XForms 1.0, published by the W3C in 2003, includes this functionality, separates the data structure from the UI, and improves communication with the server. Good luck finding a browser that supports it though. Yet another case of the "glacial" W3C being blamed for browsers not keeping up with them.

CSS2 is still in the works. The final version has still not been published.

Recommendation is as close to "final" status as you can get out of W3C. This page claims that CSS2 became a Recommendation in May 1998, over a decade ago. Or were you thinking of CSS2.1, which has been a Candidate Recommendation for a couple weeks shy of a year, or CSS3, which is still a Working Draft?

CSS2 is still in the works. The final version has still not been published.

Recommendation is as close to "final" status as you can get out of W3C. This page claims that CSS2 became a Recommendation in May 1998, over a decade ago. Or were you thinking of CSS2.1, which has been a Candidate Recommendation for a couple weeks shy of a year, or CSS3, which is still a Working Draft?

CSS 3 is a family of specifications, not a single specification. Some of those too are at candidate recommendation stage, ready for implementing, just like CSS 2.1.

In any case, what's your point? I mentioned CSS 2 because it was published by the W3C a decade ago and its features are still not available to most web developers because Internet Explorer doesn't support it. How is the fact that the W3C carried on and started working on CSS 3 relevant? It still means the bottleneck is Internet Explorer, miles behind the "glacial" W3C.

CSS2 is still in the works. The final version has still not been published.

This is simply not true. The CSS 2 recommendation was published on the 12th of May 1998.

You may be thinking of CSS 2.1, which is a candidate recommendation. What this means is that it is ready to be implemented. In order for it to reach final recommendation status, there needs to be at least two interoperable implementations for every feature. To achieve that, browser vendors need to go ahead and implement it.

CSS2 is still in the works. The final version has still not been published.

This is simply not true. The CSS 2 recommendation was published on the 12th of May 1998.

You may be thinking of CSS 2.1, which is a candidate recommendation. What this means is that it is ready to be implemented. In order for it to reach final recommendation status, there needs to be at least two interoperable implementations for every feature. To achieve that, browser vendors need to go ahead and implement it.

There are also problems with the lack of any kind of dynamic font loading to use custom fonts in a web page.

The W3C put font loading into the CSS 2 specification over a decade ago. The browser vendors ignored it until recently. Now, ten years later, the browser vendors are starting to implement it, and apparently this means the W3C moves too slowly?

Just keep in mind, there's nothing stopping web developers from using straight HTML, CSS, JPG, PNG and GIF for basic animation.

The key word there is BASIC. Complex animations, applications, and games are where Flash excels. Web Browsers did not provide sufficient facilities until recently. And only then because the browser makers got fed up with the W3C's stance that HTML did not need to be updated, and ended up doing an end run around their process. In result, most web browsers (except IE, surprise, surprise) support APIs for complex animations. They are also adding support for long term storage, sophisticated networking, predictable parsing, and other features that will greatly aid web developers.

This minor coup has not gone unnoticed by the W3C. In order to maintain the coherency of their organization, they went ahead and accepted HTML 5 as a working draft. The specification is getting top priority and is being handled in an open manner that is most unlike the W3C's business as usual. In other words, a win for both browser and web app developers. :-)

You took the words right out of my mouth.

This, of course, would be a monumental undertaking -- basically creating a security access tunable virtual window into multiple OSs with a consistent display of graphical user interface with full multimedia capabilities worthy of building quality simulations/games - in addition to your standard office type applications and persistence capabilities. This would take a large team to build, with the expectation that it would be used as a framework by large numbers of developers; the W3C's view of these kinds of capabilities is only in its infancy - via the Web Applications Working Group, and what is there looks less ambitious than we are talking about here.

According to W3C, the web is "the universe of network-accessible information, the embodiment of human knowledge."

That's why the aliens haven't published any websites yet...

If you're going to nitpick, probably a good idea to learn about the difference between HTML and HTTP first, eh?

...and to understand that FTP resources are also part of the web.

According to W3C, the web is "the universe of network-accessible information, the embodiment of human knowledge."

Some of the stuff under question is applications for using information, not information itself, and thus isn't really part of the "web" in that sense. A bunch more - perhaps the majority - neither contains nor uses actual information, except in the information-theoretic sense in which noise has more "information" than signal...

http://www.w3.org/html/wg/html5/#width4

You're probably thinking of XHTML 2.0, though img is still present there. HTML 5 came about when Apple, Mozilla, and Opera decided they didn't like where XHTML was going. They started the WHATWG, and made a draft of HTML 5. The W3C has since restarted development on HTML, and it looks like XHTML 2.0 may be dead before it's even started. HTML 5 can be formulated as XHTML anyway (XHTML 5), where we will finally dump the whole DOCTYPE pointlessness and make it clear that it's the internet media type and not the DOCTYPE that makes an XHTML document.

You're probably thinking of XHTML 2.0, though img is still present there. HTML 5 came about when Apple, Mozilla, and Opera decided they didn't like where XHTML was going. They started the WHATWG, and made a draft of HTML 5. The W3C has since restarted development on HTML, and it looks like XHTML 2.0 may be dead before it's even started. HTML 5 can be formulated as XHTML anyway (XHTML 5), where we will finally dump the whole DOCTYPE pointlessness and make it clear that it's the internet media type and not the DOCTYPE that makes an XHTML document.

There is an effort under way to publish a revision to the HTTP 1.1 specification, and the connection limit is one of the things that may change. The relevant thread on the mailing list starts here.

native support for video (in the form of the tag and a Free codec such as Ogg Theora). The latter is actually already written, but Mozilla isn't going live with it yet because of patent fears from certain large companies.

I thought that was because it just wasn't finished in time for Firefox 3.0, hence why they're implementing it in Firefox 3.1 instead. If Mozilla are worried about submarine patents, they've kept that very quiet. Apple have been quite vocal of their worries about submarine patents in Theora, while Nokia seem to have objected without knowing quite what it is they're objecting to, but Mozilla supported making it a part of the HTML 5 spec.

HTTP already has a way to handle languages: the Accept-Language header (section 14.4 of that link). Country TLDs make sense because a website may be associated with a specific country, but unless .en is for websites about English, it does not make any sense.

You mean like a formal standard for the language? That's ECMAScript. Do you mean a standard way of interfacing with the browser? That would be DOM. Or do you mean some practical tests of scripting to ensure that different browsers behave consistently? Sounds like Acid3.

Would you mind basing your claims on something? I have just tried about a quarter of the w3c's SVG 1.1 Full test suite and got perfect results (as far as I can tell), in Opera. Please supply a counter-example, would you?
The same goes for XSLT/XML. Please pardon my ignorance as I'm only aware of two examples of proper XSLT used "in the wild": Blizzard's WoWArmory and FeedBurner's feeds. Both work perfectly in Opera 9.5, though the former requires "Mask as Firefox" so it's not delivered in plain-old XHTML.
Anyways, I did put up with enough examples. Please follow suit or shut up.

I have predicted it on the day when Gmail introduced Firefox to the Google Pack, only to get laughed at by the Slashdot crowd. In this case it is sad to have been right but let's face it - we had it coming. And for those who are posting messages about how Micro$oft can't make a correct website - do you think that they have missed the campaign? I wish. The truth is that they are some of the most knowledgeable folks out there, even if on the evil side of our battle. Sadly the only solution is to do what we have done in the same situation with Open Office having problems with Office generating incorrect documents. We had to cripple Open Office internal file importation algorithms to the point of having tons of slow spaghetti code (take a look at the CVS sometimes) but what was the other alternative? We could have only excluded ourselves from the main stream of de facto standards. Now the Firefox team stands before the same dilemma. Let's just hope that they will solve this problem wisely and elegantly. They need our support now, for they will not get it from Redmond.

I have predicted it on the day when Gmail introduced Firefox to the Google Pack, only to get laughed at by the Slashdot crowd. In this case it is sad to have been right but let's face it - we had it coming. And for those who are posting messages about how Micro$oft can't make a correct website - do you think that they have missed the campaign? I wish. The truth is that they are some of the most knowledgeable folks out there, even if on the evil side of our battle. Sadly the only solution is to do what we have done in the same situation with Open Office having problems with Office generating incorrect documents. We had to cripple Open Office internal file importation algorithms to the point of having tons of slow spaghetti code (take a look at the CVS sometimes) but what was the other alternative? We could have only excluded ourselves from the main stream of de facto standards. Now the Firefox team stands before the same dilemma. Let's just hope that they will solve this problem wisely and elegantly. They need our support now, for they will not get it from Redmond.

ODF documents should be checkable, and compliant applications should have the opportunity to flag errors on the format.

It's localization and language problem, not a geolocation problem. Where you are or where they think you are has nothing to do with the problem. Quebec is officially bilingual English and French, so while you are correct in that the services like Yahoo! are wrong to serve you French ads, it's because they are ignoring your browser's language preference settings.

Many other countries and regions have more than one official language. It's pathetic to see the slow, steady evaporation of technical knowledge in the market. Ten years ago, anyone and everyone working with WWW services knew how to deal with user-specified language preferences and, where more than one language was required, used the HTTP content negotiation. It's very easy in Apache to support this HTTP function. For Lighttpd you need a lua script, but that too is easy. For Yahoo or Google, they have their own home grown HTTP servers, so have to file a bug report directly with them.

My current work environment seems to be quite similar to yours. Although I do not consider myself a master, I'm definitely a jack of all trades. Fax machines, copiers, computer networks (Linux, Windows), Intranet sites design, etc.

How do I keep current? Just reading the manuals.

• Web design? w3.org / www.php.net
• Networks? Microsoft Support
• Copiers, faxes and other hardware? manufacturers' sites

This is honestly where i've learned all what i know now.

It's as screwed up there as elsewhere. Maybe they should try creating valid HTML and/or CSS at some point, as neither the HTML nor the CSS seems to validate.

It's as screwed up there as elsewhere. Maybe they should try creating valid HTML and/or CSS at some point, as neither the HTML nor the CSS seems to validate.

We'll just make our own APIs for interacting with XML documents... with blackjack... and hookers!

(P.S. Please mod parent Off-Topic or Overrated. It's not even a good troll.)

We'll just make our own APIs for interacting with XML documents... with blackjack... and hookers!

(P.S. Please mod parent Off-Topic or Overrated. It's not even a good troll.)

We'll just make our own APIs for interacting with XML documents... with blackjack... and hookers!

(P.S. Please mod parent Off-Topic or Overrated. It's not even a good troll.)

<!DOCTYPE html>
<title>MathML test</title>
<p>Here's an equation: <math><msup><mi>e</mi><mrow><mi>i</mi><mi>&pi;</mi></mrow></msup><mo>+</mo><mn>1</mn><mo>=</mo><mn>0</mn></math>