Re: The xhtml:onkeypress architecture

Bjoern Hoehrmann wrote:
>   Congratulations for getting XHTML Modularization 1.1 to PR so quickly.

Thanks. Getting the same methodology to work consistently in both DTDs 
and XML Schema was a lot of work.

> XHTML Modularization teaches most
> fascinating ways to use obsolete technologies like XML DTDs to build new
> schemas that, while unsuitable for validation, surely serve a purpose.

Actually, the very thing that 1.1 adds is XML Schema.

Modularization certainly does serve a purpose, for instance keeping a 
handle on different language profiles, such as XHTML Basic, Print and 
1.1, and documenting extension points to ease the process of combining 
different schemas, as Masayasu Ishikawa demonstrated in his 
XHTML+MathML+SVG profile (http://www.w3.org/TR/XHTMLplusMathMLplusSVG/), 
therefore making it easier to define extensions (or contractions) to XHTML.

I also know several people who use it for validation purposes, and 
others for generating editors.

Several external groups use it. Jabber for instance:
http://www.jabber.org/jeps/jep-0071.html

James Clark did a TREX version: http://www.thaiopensource.com/trex/xhtml/

> I'm glad the HTML Working Group, although expired in 2004, managed to
> skip the Last Call and Candidate Recommendation steps

We didn't skip last call. As the status section of Modularization 
explains, Modularization 1.1 is a combination of an existing 
recommendation, which has been through last call, with a new appendix 
for XML Schema, which also went through last call.

Modularization is a methodology on how to use existing technologies, not 
a technology in itself, comparable with, for instance, microformats, 
which takes an existing technology and describes how to use it in a 
certain compatible way.

So as long as the underlying technology is there, it just works. W3C 
process allows a zero-length CR period.

> and I'm glad to
> see the Implementation Report, although marked as "XHTML-Print"

Does it? Oh yes, in the <title>. Thanks for spotting that; fixed.

> Implementation Report and W3C Proposed Recommendation, confirms that
> all the major XHTML implementations, Eclipse, oXygen, Sidewinder, and
> XFormation, are conforming XHTML implementations.

They can all handle XHTML *Modularization*.

> In addition to enlightened DTD-writing methodologies the document also
> teaches an unprecedented way of exporting attributes for use in compound
> document environments; I'm excited about the possibilites the xhtml:id,
> xhtml:style, and xhtml:onkeypress attributes offer to content authors.
> 
> Nevertheless, given that the HTML Working Group's response to my request
> to ask the TAG to review this new aspect of XHTML Modularization--"Its
> our language and we can do that"--didn't really remove my architectural
> concerns

It is not unprecedented in any respect.

HTML and XHTML have what are called there 'common' attributes, such as 
id, class, and style, that apply across the whole language: you can use 
them on any element. What we have done is put these attributes in the 
global partition of the namespace, as the namespace spec defines, so 
that when you create a markup language that combines XHTML with some 
other markup (MathML for instance) those attributes are still available 
on every element in a consistent way. This is not new, and follows 
existing specifications. In fact the Namespace spec even has an example 
of using html:class in this way.

> I would appreciate if the HTML Working Group could document
> the design principles established by this new feature in a better way
> than marking this issue as unresolved in the Group's issue tracker,
> 
>   http://hades.mn.aptest.com/cgi-bin/voyager-issues/Modularization-abstractions?page=2
>   http://hades.mn.aptest.com/cgi-bin/voyager-issues/Modularization-abstractions?id=8444

You are right that we did forget to mark those as closed.

As to your remark that exporting 'title' as a global attribute 
introduces a clash in the namespace with the title element, you need to 
read "A.2 XML Namespace Partitions" 
http://www.w3.org/TR/REC-xml-names/#ns-breakdown, which explains that 
namespaces have three partitions, one for elements, one for global 
attributes, and one for per element attributes.

Your other comments don't concern the TAG, so I will handle them 
separately with the HTML WG.

Thanks for your comments as always. I hope that it is now clear that the 
namespace spec defines this behaviour already, and we are just 
documenting how it applies to the XHTML family.

Best wishes,

Steven Pemberton

> In fact, I think documenting rationale for decisions is generally a good
> practise, for example, I'm sure the microformat community would like to
> know why using multiple resource identifiers in the profile attribute on
> the head element is prohibited in XHTML Modularization as noted in
> 
>   http://hades.mn.aptest.com/cgi-bin/voyager-issues/Modularization-abstractions?id=8168
>   http://hades.mn.aptest.com/cgi-bin/voyager-issues/Modularization-text?id=8161
>   http://hades.mn.aptest.com/cgi-bin/voyager-issues/HTML-4.01?id=6383
>   ...
> 
> Here again I think marking these issues as unresolved is suboptimal
> given the maturity level of the document. Your HTML and XForms Working
> Group's sincere dedication to the W3C Process is widely recognized as
> exceptional in their respective communities; I could imagine that the
> Working Group simply didn't get around to update the tracker with the
> latest information from the transition call yet; I'm just saying a
> separate document that discusses how the community should embrace the
> decisions and new principles would be nice.
> 
> Thanks again,

Received on Tuesday, 14 February 2006 12:59:27 UTC