Re: HTML5 and XHTML2 combined (a new approach)

Hi Benjamin,

I think you make some fair points.

However, I don't agree that modularisation is of no value, since not
only is it being used by various language designers for a variety of
uses, but it also opens up the possibility that different interest
groups can work on different parts of the 'larger' vision.

For example, the organisations and individuals involved with XForms
are very different to those involved with XHTML 2, yet XForms began as
an XHTML module. Nowadays though, there are implementations that use
HTML, XHTML 1.x, and of course XHTML 2 as the host language for
XForms, mainly because it was modularised.

An even more striking example is RDFa; it also began life as an XHTML
2 module, yet is now a richer product for having been worked on by a
combination of people from the HTML, XHTML, Microformats and semantic
web communities.

But I do agree with you that the ability to modularise is not the most
significant part of XHTML 2; I think there are other far more powerful
advantages.

In my view, the most important aspect of XHTML 2, and where it breaks
new ground, is that it makes author extensibility a central design
goal, rather than an accidental add-on.

I saw some code yesterday where a site was using the @rel attribute to
hold some JavaScript object definitions:

  <a href="..." rel="{a :b;}">...</a>

And why shouldn't they? If you want to use declarative constructs, or
unobtrusive techniques, you are pretty much forced to do this kind of
thing -- or use other attributes such as @class, with convoluted
formats -- unless you go off and invent new markup.

The early work on XHTML 2 looked again at how a markup language can
provide well-defined points that authors, and the organisations they
work with, can use to enrich their documents -- but without breaking
the markup.

XHTML 2 provides two key extension points, in the form of the role
attribute (now implemented in both Firefox and IE8), and RDFa
(supported by Yahoo!'s SearchMonkey, Creative Commons, a number of UK
government sites, and even being added to Drupal core).

I think what many people don't realise in these discussions about
languages, is that this is essentially the core of the difference
between HTML5 and XHTML 2 -- HTML5 is about a monolithic spec,
individually authored, making a *virtue* out of having no extension
points, whilst XHTML 2 is about bending over backwards to add
extension points to the language *itself*, so that authors and
organisations are not beholden to the standards process.

This last point about the standards process is rather ironic, since
when the WHATWG came onto the scene it had some healthy -- and to my
mind reasonable -- criticisms of the W3C process, yet far from
replacing them with anything new, seems now to be even more
restrictive.

Anyway, yesterday I happened to blog in a lot more detail about the
extension points that RDFa and @role bring to markup languages,
explaining at the same time why the very act of providing extension
points runs counter to the HTML5 approach to language design. The post
is here, for anyone interested in this topic:

  <http://webbackplane.com/mark-birbeck/blog/2009/01/rdfa-means-extensibility>

Regards,

Mark

On Wed, Jan 21, 2009 at 11:38 PM, Benjamin Hawkes-Lewis
<bhawkeslewis@googlemail.com> wrote:
>
> On 21/1/09 20:30, Giovanni Campagna wrote:
>>
>> The biggest advantage of XHTML1.1/2 is modularization
>
> Is it?
>
> How does modularization of XHTML help content producers, user agent
> developers, or end-users in practice?
>
> Has it ever helped you?
>
> How would modularization of XHTML help achieve the stated goals of the HTML
> WG?
>
> I've yet to be persuaded that modularization of XHTML actually works or
> that, if it did work, it would make the Web better.
>
> The core idea of modularization, as far as I can gather, was that user agent
> developers could declare the modules they support and that content producers
> could match their content to that support profile:
>
> http://www.w3.org/TR/1999/WD-html-in-xml-19990224/#mods
>
> Whether this sort of fragmentation of the Web is remotely desirable is open
> to debate; personally I want access to _the_ Web on my phone (and my TV and
> my fridge and my cyborg cat), not lots of little walled garden webs.
>
> But in any case, when people actually try to use those modules, they seem to
> find they cannot declare a profile in terms of the because it's rather
> difficult to carve up XHTML features into useful groups.
>
> The Open Mobile Alliance defined a profile of XHTML for mobile devices that
> included various XHTML modules. But we find this statement in their
> specification:
>
> "The XHTML Mobile Profile document type could also serve as a host language,
> that is, a language containing a mix of vocabularies within one document
> type. Those considering its use as a host language should consider that it
> is not strictly XHTML Host Language Conforming, as it only partially
> includes three modules."
>
> OMA wanted XHTML MP to include "start" and "value" out of the Legacy module,
> "b", "big", "hr", "i", and "small" out of the Presentation module, and
> "fieldset" and "optgroup" out of the Forms module.
>
> http://www.openmobilealliance.org/tech/affiliates/wap/wap-277-xhtmlmp-20011029-a.pdf
>
> Isn't a lesson to be drawn that language designers are going to cherrypick
> features not modules, and that, if they are going to do that, they are going
> to need to declare what features they support rather than what modules?
>
>> "Another serialization for XHTML" that defines a
>> processing model (maybe based on real SGML)
>
> If it was based on real SGML then it wouldn't be useful for processing the
> existing text/html web corpus, and it wouldn't be implemented by popular
> user agents.
>
>> This way we can allow modularization and extensiblity (since content
>> model and start/end tag handling are not defined in the same
>> specification), although we may need to get DTDs back.
>
> How does defining the content models of elements in one document and the
> implied opening/closing tags of the same elements in another document allow
> "modularization and extensibility" in a way that defining them in same
> document does not?
>
>> All the rest of HTML5 (DOM3 HTML - Scripting Execution Contexts -
>> Persistent Storage API - Advanced Network Communications API) are in
>> scope of WebApplications WG, and many people inside and outside the HTML
>> WG would rather have them separated.
>
> Many people certainly would. Indeed HTML WG/WHATWG are taking steps to spin
> some of HTML5's tangle out into other specifications. For example, Hixie has
> submitted Web Sockets as an IETF RFC:
>
> http://bgp.potaroo.net/ietf/all-ids/draft-hixie-thewebsocketprotocol-01.txt
>
> However, what is needed is not people saying these components should be in
> separate documents but people capable and willing to edit those documents.
> It's not like people are very actively editing the Web Applications drafts
> at the moment.
>
>> In conclusion, the only way to get XHTML widely deployed and implemented
>> (and thus to reach PR) is to get rid of HTML5. Start working immediately
>> at the XHTML WebApps module, before it's too late.
>
> This still seems like a proposal to turn XHTML 2 _into_ HTML5, without any
> attempt to gauge whether that meets the stated goals of XHTML 2. In
> particular, the emphasis on web applications seems at odds with XHTML 2's
> emphasis on documents.
>
> --
> Benjamin Hawkes-Lewis
>
>



-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Thursday, 22 January 2009 16:01:18 UTC