Re: Fwd: HTML5 and XHTML2 combined (a new approach)

Benjamin Hawkes-Lewis 1)
if you conversely think that HTML5 and XHTML2 have the same destinataries,
then you agree that you need one language with both features

B. Hawkes-Lewis 2)

> What we're discussing is helping implementers, isn't it? If so, then
> implementation issues are relevant.
>
Changes to monolithic languages affect all implementation (module based or
not). Changes to certain modules affect only same implementations


> How does having an implementation of XBL count as implementing
> href-on-any-element for XHTML 2? Authors being able to fake
> href-on-any-element with XBL isn't the same thing. Therefore, it would
> require code changes.
>
One of XBL2 use-case is to provide UA processing of markup languages. So an
implementation could actually use XBL2 for action, as it uses CSS for
styling. But this tangential to the discussion.


> UAs aren't required to implement any W3C Recommendations.
>

I said "asked" not "required". And many authors are asking loudly for XBL2
implementation.

>
> [...]
>

>  I asked a different question: why an author that doesn't rely on script
>> (or an implementation that cannot, for various reason, implement
>> scripts) should learn a plenty of DOM interfaces and APIs?
>>
>
> DOM is the abstract model that serializations express. So if an
> implementation is parsing a serialization, it's producing a DOM, regardless
> of whether it supports scripting.

What about SAX parsers? They don't build any DOM. An implementation is
required to build an Infoset (abstract concept), not a DOM (a set of objects
implementing certain interfaces)


>
> What is a UA that does not implement scripting required to implement by
> (unmodularized) HTML5 that you believe such a UA should not be required to
> implement? Note the differing conformance requirements for differing types
> of user agent noted in:
>
> http://www.whatwg.org/specs/web-apps/current-work/#conformance-requirements
>
What for new user-agents not covered in that section? Will the spec be
errated any time someone invents a new tool to use with (X)HTML?

>
> As for authors, I don't understand your concern. Authors are free to read
> the parts of documents they are interested in, just as they are free to read
> the documents they are interested in.
>
Yes, but it is easier to read only the page containing the feature I want,
then to search an heavy and difficult document, with the features I need
spreaded all across and concept I may not have any idea what they mean.


>  The DOM - the abstract document model - into which serialization is
> parsed, separates syntax from vocabulary in HTML5. Consequently, HTML5 has a
> text/html serialization, an XML serialization, and could (if one wanted to
> design one) have additional serializations, including a non-XML SGML
> serialization. It just wouldn't be realistic to serve them as text/html.
>
The fact is that the HTML5 parser needs to now about the elements, ie the
DTD is hardcoded inside the algorithm.

>
> Putting the processing rules for text/html in a separate specification from
> the HTML5 DOM and vocabulary would not really make it technically easier to
> reuse text/html processing for new vocabularies.
>
Why?


>  So make smaller releases containing new features that are sensible,
> settled, and implemented, rather than giant new releases with lots of
> features. No need for separate specifications to unblock new features.

You need extensibility to add new features without replacing completely
previous language. HTML5 is by design not extensible


>
>  Well maybe Image module or Table module needed a new version, but I'm
>> sure that there are features just copied from HTML4 / XHTML1 / DOM2HTML
>> etc.
>>
>
> Leaving aside the algorithms for how to parse text/html streams into a DOM,
> do you have any example of a module in XHTML1.x that is totally unaltered -
> other than not being modularized - in HTML5?

Text Module, Text Extension Modules, Form Modules (extended not replaced),
Intrinsic Events Module, Object Module, Iframe Module, Metainformation
Module, Scripting Module, Stylesheet Module, Link Module, Base Module, Name
Indefication Module. Also Table Module is very similar (I actually don't
understand why there is a processing model: doesn't CSS21 includes the same
things?)


>
> Do you have any example of a module in XHTML1.x that is unaltered in
> XHTML2?

Actually unaltered no. Mostly equivalent: Core Attributes, Core Modules
(many features just moved, with same new features), Table Module (only
summary added).

2009/1/26 Ian Hickson <ian@hixie.ch>

> On Sun, 25 Jan 2009, Giovanni Campagna wrote:
> >
> > I'm not asking to get SGML back. I'm asking to separate syntax from
> > vocabulary, and possibly apply this new syntax to any W3C or externally
> > defined language based on XML, providing an appropriate way to switch
> > between languages (the old DTD)
>
> HTML5 already separates the syntax of text/html from the HTML5 vocabulary
> as much as is possible given our constraints, for practical reasons
> regarding the way HTML is processed (there are tools that parse it without
> being concerned about its vocabulary, so separating the two in the spec
> makes sense from a pragmatic point of view).


No, because, as I already answered to Benjamin, you need to know about HTML5
vocabulary in order to implement the HTML5 algorithm. Otherwise you need a
self-describing serialization, ie XML or SGML.

>
> However, I don't think it makes sense to apply the HTML syntax to other
> languages, any more than one should reuse the CSS, JavaScript, or ISO8601
> syntax for other languages. Do you think we should separate those out for
> reuse as well?
>
I was actually thinking of SVG, SMIL, XForms: what the CDF WG is working on.
For MathML, for example, you needed to modify the algorithm.  Will you do
that with any language and, most important, any new version of those
languages? Or you want that serialization to apply only to HTML5 and MathML?
Are those languages nicer than the others?

Giovanni