Re: HTML5 and XHTML2 combined (a new approach)

>
> I've yet to be persuaded that modularization of XHTML actually works or
> that, if it did work, it would make the Web better.
>

http://www.w3.org/TR/xhtml-modularization/introduction.html#s_intro_whatisxhtml

--
Brett P.


On Wed, Jan 21, 2009 at 6: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
>
>