Xhtml 1 or html 5

[Force Flow]

1) XML is still used. AJAX and RSS are real-world examples of XML in use. XML can also used as flat-file databases.

2) On a personal note, I was a big fan of the XHTML syntax because it was semantically correct (in terms of a tag-based language, anyway). But, now, I don't really care too much either way. I've moved away from it and gone with HTML5--even though I don't use many of its features, it's simply the new direction of the web. HTML5 can be written in the XHTML or traditional HTML syntax if you still prefer one way or the other.

[felgall]

Because that's the exact moment when they have to implement graceful degradation for badly written XHTML docs. Since this is the moment when HTML started to get a bad name, when they had to account for any malformed web page and still render it, no matter what.

I hope not - the best part of XHTML is that browsers refuse to display the page at all if there are ANY XHTML errors. Unfortunately some browsers have already b roken the rule about refusing to serve badly written XHTML.

What's the point of XHTML if the browsers will accept any old errors the way they do with HTML - might as well stick with HTML if you want the browser to fix your errors for you.

[Jeff Mott]

Furthermore, I'm not looking forward to live-debugging my web pages by serving users stopped renderings.

What would be really interesting is if we could tell the browser -- either through an HTTP header or a meta tag -- whether it should error correct or fail. That way, we could set it to fail in dev environments but error correct in production.

[itmitică]

What's the point of XHTML if the browsers will accept any old errors the way they do with HTML - might as well stick with HTML if you want the browser to fix your errors for you.

Because that's not the main feature of XHTML, syntax strictness. Like I said before, we could have had that with HTML. HTML docs could have as well break rendering upon any error, big or small, but it turns out that that's not a valid scenario in the real world. And once XHTML joins the mainstream, breaking the rendering on any errror, big or small, it won't be a valid scenario either.

So forget about syntax, it's a small fish to fry and strictness it's something HTML could have done it itself. Most importantly, the gains of using XHTML are things like interoperability, namespaces, new elements and such. Though since SVG and MathML are available with plain HTML in HTML5 semantics, using something like a XHTML <object> for this type of integration inside a HTML document would be best, IMO.

[itmitică]

XML is still used. AJAX and RSS are real-world examples of XML in use.

WebSockets, hopefully, will replace AJAX. Or any other AJ***. Maybe even AJAJSON.

RSS is becoming redundant. (Apple drops RSS in OS X 10.8 Mountain Lion.)

XML can also used as flat-file databases.

Too verbose for that. JSON, YAML,...

[itmitică]

we could set it to fail in dev environments but error correct in production.

Simply put, the web will never be the place where browser vendor punish web developers for syntax errors in extreme ways. Especially since it may not even be the web developer's fault, but a crazy glitch in one of the supporting systems.

[Force Flow]

WebSockets, hopefully, will replace AJAX. Or any other AJ***. Maybe even AJAJSON.

The point is that XML is still in active use. It hasn't been abandoned. I'm just not sure why you are so vehemently against it.

WebSockets are interesting, but since most browsers out in the wild don't actually support them, they are impractical for real-world use.

Off Topic:

Especially until 2017. This is when support Windows Vista ends, and Microsoft has already stated that IE9 will be the lastest browser version deployed to Vista. WebSocket support is planned for IE10.

RSS is becoming redundant. (Apple drops RSS in OS X 10.8 Mountain Lion.)

Redundant how? What's replacing it?

All apple did was remove it from their browser and mail applications (as a side note: I've been questioning some of Apple's strategies and decisions as of late; this being one of them). RSS is also still supported through Apps in the app store. Other browsers still support it, and there are plenty of other 3rd-party stand-alone RSS readers still available.

Too verbose for that. JSON, YAML,...

JSON is great for transferring simple data. JSON is strongly tied to Javascript, while XML is language-independent. XML tends to be a better for longer-term storage because it's structured and standardized. And XML can be as verbose or as concise as you want it to be.

Here's a quick comparison between what you can do with JSON and what you can do with XML.

JSON:

{    "firstName": "John",
    "lastName": "Smith",
    "age": 25,
    "address": {
        "streetAddress": "21 2nd Street",
        "city": "New York",
        "state": "NY",
        "postalCode": "10021"
    },
    "phoneNumber": [
        {
            "type": "home",
            "number": "212 555-1234"
        },
        {
            "type": "fax",
            "number": "646 555-4567"
        }
    ]
}

XML:

<person firstName="John" lastName="Smith" age="25">
  <address streetAddress="21 2nd Street" city="New York" state="NY" postalCode="10021" />
  <phoneNumbers>
     <phoneNumber type="home" number="212 555-1234"/>
     <phoneNumber type="fax"  number="646 555-4567"/>
  </phoneNumbers>
</person>

(Source: http://en.wikipedia.org/wiki/JSON#XML)

YAML is problematic because it isn't a tag-based language, but a tab-delimited based language. It's way too easy to end up with a malformed document, and thus makes it impractical. With XML, formatting and spacing doesn't matter since it's a tag-based language (although it helps so that the data is more easily human-readable).

[itmitică]

I'm just not sure why you are so vehemently against it.

I'm not against it, I'm pointing out what XML is not. Yes, is still active, and I've said that my self, but only because of backward compatibility issues. But it stopped having a future.

Here's a quick comparison between what you can do with JSON and what you can do with XML.

Wikipedia is not the best reference to quote, and, as such, you are inaccurate on a number of things.

1. XML can be as verbose or as concise as you want it to be.
That's a hack and you know it. No serious data storage is going to use attributes instead of nodes for information.

1. JSON is strongly tied to Javascript.
Wrong.
http://www.json.org/

JSON is a text format that is completely language independent.

2. XML tends to be a better for longer-term storage because it's structured and standardized.
Wrong again.
Here's are the languages with JSON implementations:
http://www.json.org/

ASP:
JSON for ASP.
JSON ASP utility class.
ActionScript:
ActionScript3.
JSONConnector.
Ada:
GNATCOLL.JSON.
Bash:
Jshon.
JSON.sh.
BlitzMax:
bmx-rjson.
C:
JSON_checker.
YAJL.
js0n.
LibU.
json-c.
json-parser.
jsonsl.
M's JSON parser.
cJSON.
Jansson.
jsmn.
cson.
C++:
JSONKit.
jsonme--.
ThorsSerializer.
JsonBox.
jsoncpp.
zoolib.
JOST.
CAJUN.
libjson.
nosjob.
rapidjson.
C#:
fastJSON.
JSON_checker.
Jayrock.
Json.NET - LINQ to JSON.
LitJSON.
JSON for .NET.
JsonFx.
JSON@CodeTitans
How do I write my own parser?
JSONSharp.
JsonExSerializer.
fluent-json
Manatee Json
Clojure:
clojure-json.
API for json.
Cobol:
XML Thunder.
ColdFusion:
ColdFusion 8.
toJSON.
D:
Cashew.
Libdjson.
Dart:
json library.
Delphi:
Delphi Web Utils.
JSON Delphi Library.
JSON Toolkit.
tiny-json.
E:
JSON in TermL.
Erlang:
ejson.
mochijson2.
Fantom:
Json.
Go:
package json.
Haskell:
RJson package.
json package.
haXe:
hxJSON.
Java:
org.json.
org.json.me.
Jackson JSON Processor.
Json-lib.
JSON Tools.
Stringtree.
SOJO.
Jettison.
json-taglib.
XStream.
Flexjson.
JON tools.
Argo.
jsonij.
fastjson.
mjson.
jjson.
json-simple.
json-io.
JsonMarshaller.
google-gson.
Json-smart.
JavaScript:
JSON.
json2.js.
json_sans_eval.
clarinet.
Lisp:
Common Lisp JSON.
Yason.
Emacs Lisp.
LotusScript:
JSON LS.
Lua:
Json4Lua.
LuaJSON.
LuaJSON C Library.
Fleece.
Lua CJSON.
dkjson.
Matlab:
JSONlab.
JSON Parser.
(another) JSON Parser.
Objective C:
json-framework.
MTJSON.
JSONKit.
yajl-objc.
TouchJSON.
OCaml:
Yojson.
jsonm.
OpenLaszlo:
JSON.
Perl:
CPAN.
perl-JSON-SL.
PHP:
PHP 5.2.
json.
Services_JSON.
Zend_JSON.
Solar_Json.
Comparison of php json libraries.
Pike:
Public.Parser.JSON.
Public.Parser.JSON2.
PL/SQL:
pljson:
Librairie-JSON.
PowerShell:
PowerShell.
Prolog:
SWI-Prolog HTTP support
Puredata:
PuRestJson
Python:
The Python Standard Library.
simplejson.
pyson.
Yajl-Py.
ultrajson.
Qt:
QJson.
R:
rjson.
Racket:
json-parsing.
Rebol:
json.r.
RPG:
JSON Utilities.
Ruby:
json.
yajl-ruby.
json-stream.
Scala:
package json.
Scheme:
MZScheme.
PLT Scheme.
Squeak:
Squeak.
Symbian:
s60-json-library.
Tcl:
JSON.
Visual Basic:
VB-JSON.
PW.JSON.
Visual FoxPro:
fwJSON.
JSON.

3. And XML can be as verbose or as concise as you want it to be.

While this "postalCode": "10021" will always be shorter then this <postalCode>10021</postalCode>, JSON can also be as concise as you want it to be:

"address": {
        "21 2nd Street",
        "New York",
        "NY",
        "10021"
    },

http://www.json.org/

JSON is built on two structures:

A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array.

An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.

These are universal data structures. Virtually all modern programming languages support them in one form or another. It makes sense that a data format that is interchangeable with programming languages also be based on these structures.