Barrapunto

Algunas correcciones:

• Object no es nuevo, al contrario, es muy viejo, y ya estaba en HTML 4. La última vez que lo probé, no estaba soportado por explorer (y creo que no han cambiado nada en explorer en este tiempo), así que por eso nadie lo debe estar usando.
• Lo de «Validación XML obligatoria», no tiene sentido. Los documentos XML se pueden clasificar entre bien formados y mal formados. Los bien formados, pueden además ser válidos, o no. Lo primero se aplica al XML, en general, sin que pertenezca a ningún vocabulario en concreto, y lo segundo, la validación, sólo tiene sentido si estamos hablando de un vocabulario en concreto (XHTML, DocBook, etc.). Un parser XML no suele trabajar con documentos que no estén bien formados, ya que si el documento no está bien formado, no está perfectamente definido como debe comportarse. Pero si ningún navegador se comporta como un parser XML ahora (porque intenta interpretar el documento, aunque sea inválido y mal formado), con XHTML 1.1, ¿porqué iba a ser diferente en 2.0? Dudo mucho que cambie nada al respecto.
• Las inclusiones XML, como su espacio de nombres indica, no son parte de XHTML, sino de un estándar aparte llamado (lógicamente) XML Includes. Puede parecer una tontería, pero no, porque de aplicar el mismo razonamiento, podríamos decir que XHTML 2.0 también incluye SVG.

Saludos.

Bueno, el estado actual del XHTML 2.0 es working draft [w3.org], así que es probable que cambien cosas. Y puede que <object> no sirva para todo. El principal problema es, como no, Internet Explorer, que trata los <object>... como objetos, sí, pero ActiveX (y no es el único navegador que tiene problemas con esta etiqueta). Esto no es algo que se vaya a resolver a corto plazo precisamente, y sería un grave error ignorarlo. Incluso hay quien en las listas del W3C ha sugerido una nueva etiqueta (<include> si no recuerdo mal).

Por otro lado, como ya te han dicho por ahí, las XML Inclusions [w3.org] son una recomendación aparte, y no tienen nada que ver. Puedes usarlas en XHTML porque son un mecanismo para unir documentos XML, como puedes usar MathML o SVG (siempre usando namespaces). De hecho es el único motivo razonable que veo yo para usar XHTML antes que HTML.

Y para terminar, creo que te has olvidado de lo más importante: la modularidad [w3.org]. XHTML 2.0 se basa en módulos. Es decir, ya no existe una gran DTD, sino varias: una para el documento, otra para el texto, otra para las listas, etc (en realidad ahora mismo no existe ninguna DTD, sólo esquemas [w3.org] RELAX NG [relaxng.org]). En XHTML 2.0 se definen todas menos tres: XML Events [w3.org], Ruby [w3.org], y XForms [w3.org] (sólo se define la integración). Luego en cada documento utilizas únicamente los módulos que necesites.

Coincido en que el poco exito de XHTML 1 es que sólo beneficia al navegador, de todas formas esa manera de trabajar de los navegadores tan permisiba a la hora de procesar páginas con fallos y pasar a quirksmode es un arma de doble filo, si quieres sacar un hilo rss o atom te preocupas de comprobar que es un xml válido porque sino no te va a mostrar nada, mientras que con html la mayoría ni se preocupa.

En realidad el ejemplo tiene truco ya que generar un rss es fácilmente automatizable, mientras que un html es bastante más complejo.

Quizás una banderita en el navegador diciendo que tal página es correcta o que ha tenido que pasar a quiks por múltiples fallos concienciase a más de un desarrollador web.