Re: HTML5 and XHTML2 combined (a new approach)

I do not know if I am reading this wrong, but:

http://www.w3.org/MarkUp/2000/Charter
http://www.w3.org/2002/05/html/charter

According to this, their only true goal: "To fulfill the promise of XML for
applying XHTML to a wide variety of platforms. To assist W3C's leadership
role to support rich Web contents that combine XHTML with other W3C's work
on areas such as math, scalable vector graphics, synchronized multimedia,
and forms." seems to remain intact from the last charter.

And the scope of the charter is to combine all the languages and drop HTML,
by helping to transition over from HTML to XHTML in the last of the two
links, and in the earlier of the two links, from XHTML to XML.

At least that's how i read it.

--
Brett P.


On Thu, Jan 22, 2009 at 7:55 AM, Brett Patterson <
inspiron.pattersonb@gmail.com> wrote:

> 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
>>
>>
>